Clone
2
Local Build Scripts.de
Patrick Gniza edited this page 2026-08-21 09:04:39 +02:00

Deutsch | English

Lokale Buildskripte

Lokale Image-Builds werden über spezielle Hilfsskripte ausgeführt.

docker-compose.build.yml wird nicht mehr benötigt.


Dateien

scripts/build-local.sh
scripts/build-local.ps1

Linux / macOS

chmod +x scripts/build-local.sh
./scripts/build-local.sh all

Windows PowerShell

.\scripts\build-local.ps1 -Targets all

Buildziele

Verfügbare Zielgruppen:

all
runtimes
server-runtime
gui-runtime
payload
client-payload
firebird-payload
server
admin
client
mromexis
migration
control
manifests

Beispiele:

./scripts/build-local.sh server-runtime server
./scripts/build-local.sh gui-runtime admin client
./scripts/build-local.sh migration control

PowerShell-Beispiele:

.\scripts\build-local.ps1 -Targets server-runtime,server
.\scripts\build-local.ps1 -Targets gui-runtime,admin,client

Umgebungsvariablen

Die Skripte verwenden dieselben Variablen wie die Compose-Laufzeitkonfiguration.

Wichtige Beispiele:

REGISTRY=gitea.buchhorster.de/planmeca
ROMEXIS_VERSION=6.5.3.444.203
TARGETARCH=amd64
IMAGE_SUFFIX=

ROMEXIS_IMAGE=romexis-server
MIGRATION_IMAGE=romexis-migration-service
ADMINISTRATION_IMAGE=romexis-admin
MROMEXIS_WEBAPP_IMAGE=romexis-mromexis-app
CLIENT_IMAGE=romexis-client
CONTROL_AGENT_IMAGE=romexis-control-agent
SERVER_RUNTIME_VERSION=11
GUI_RUNTIME_VERSION=1
REGISTRY_CACHE=0

Für Feature-Branches:

IMAGE_SUFFIX=-feature-romexis-admin

Abhängigkeitsauflösung und lokale Aliase

Vor dem Build eines finalen Images stellen die Skripte sicher, dass die benötigten Payload-Images verfügbar sind: Ein vorhandenes lokales Image wird wiederverwendet, andernfalls wird die Registry versucht und wenn das Image weiterhin fehlt, wird es aus den lokalen Projektquellen gebaut.

Bei PUSH=0 erhalten lokal gebaute Runtime-/Payload-Abhängigkeiten zusätzlich isolierte romexis-local/...-Aliase. Diese Aliase verhindern, dass BuildKit ein älteres Registry-Image mit demselben öffentlichen Tag auflöst. Die Aliase sind reine Build-Implementierungsdetails und werden nicht veröffentlicht.



Beziehung zu Runtime Compose

Die Buildskripte erstellen die Image-Tags, welche die Runtime-Compose-Dateien erwarten.

Runtime Compose verwendet Image-Referenzen im Manifeststil, beispielsweise:

${REGISTRY}/${ROMEXIS_IMAGE}:${ROMEXIS_VERSION}${IMAGE_SUFFIX}
${REGISTRY}/${ADMINISTRATION_IMAGE}:latest${IMAGE_SUFFIX}
${REGISTRY}/${MROMEXIS_WEBAPP_IMAGE}:${ROMEXIS_VERSION}${IMAGE_SUFFIX}

Dadurch kann dieselbe .env für lokale Builds und den Start der Laufzeit verwendet werden.

Sicherer Push und Manifest-Veröffentlichung

Ein lokaler Single-Architecture-Build mit PUSH=1 veröffentlicht nur den Architektur-Tag, zum Beispiel romexis-server:<version>-amd64. Der öffentliche Multi-Architektur-Tag wird dadurch nicht ersetzt.

Nachdem beide Architekturen gepusht wurden, werden die Manifeste explizit veröffentlicht:

PUSH=1 ./scripts/build-local.sh manifests

PowerShell:

.\scripts\build-local.ps1 -Targets manifests -Push 1


Typischer Workflow

cp .env.sample .env
nano .env

./scripts/build-local.sh all

docker compose up -d

Den ausgewählten Laufzeit-Stack untersuchen:

docker compose config