Planmeca/romexis-server-docker
Private
Public Access
5
1
Packages Wiki

Update wiki for new container and image build architecture 

- Document payload, runtime and final image separation
- Add server and GUI runtime image documentation
- Document standalone Romexis Client image and payload flow
- Update local build, Drone CI and multi-arch manifest workflows
- Add staging tags, registry caching and change detection details
- Update project structure, release process and developer documentation
- Keep German and English wiki pages structurally synchronized
patrick
2026-08-21 09:04:39 +02:00
parent 4eac47580e
commit 9b492fdac8
31 changed files with 1163 additions and 253 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Architecture.de.md
+17 -2
@@ -83,20 +83,35 @@ Der mRomexis-Proxy schreibt Backend-Proxy-Anfragen auf den internen Dienst `rome
romexis-payload:<version>
|
+--> romexis-server:<version>
|
+--> romexis-admin:<version>
|
+--> romexis-mromexis-app:<version>
romexis-client-payload:<version>
|
+--> romexis-client:<version>
romexis-base-jre:11-<arch>
|
+--> romexis-server:<version>-<arch>
romexis-gui-runtime:1-<arch>
|
+--> romexis-admin:<version>-<arch>
+--> romexis-client:<version>-<arch>
romexis-firebird-payload:latest
|
+--> romexis-server:<version>-<arch>
Independent service images:
romexis-migration-service:latest
romexis-control-agent:latest
```
Payload-Images enthalten versionsabhängige Inhalte aus dem Installer. Runtime-Images enthalten aufwendige architekturspezifische Abhängigkeiten, die über mehrere Romexis-Versionen hinweg wiederverwendet werden. Die finalen Server-, Admin- und Client-Images setzen daher im Wesentlichen ein Payload mit der passenden Runtime-Schicht und komponentenspezifischen Startdateien zusammen.
`romexis-client` erbt nicht mehr von `romexis-admin`; beide verwenden unabhängig voneinander die gemeinsame `romexis-gui-runtime`. Payload- und Runtime-Images sind Build-Abhängigkeiten und keine zusätzlichen Dienste im Runtime-Compose-Stack.
---
## Compose-Architektur
Architecture.md
+17 -2
@@ -83,20 +83,35 @@ The mRomexis proxy rewrites backend proxy requests to the internal `romexis` ser
romexis-payload:<version>
|
+--> romexis-server:<version>
|
+--> romexis-admin:<version>
|
+--> romexis-mromexis-app:<version>
romexis-client-payload:<version>
|
+--> romexis-client:<version>
romexis-base-jre:11-<arch>
|
+--> romexis-server:<version>-<arch>
romexis-gui-runtime:1-<arch>
|
+--> romexis-admin:<version>-<arch>
+--> romexis-client:<version>-<arch>
romexis-firebird-payload:latest
|
+--> romexis-server:<version>-<arch>
Independent service images:
romexis-migration-service:latest
romexis-control-agent:latest
```
Payload images contain version-specific installer content. Runtime images contain expensive architecture-specific dependencies that are shared across Romexis versions. The final Server, Admin and Client images therefore mainly assemble a payload with the appropriate runtime layer and component-specific startup files.
`romexis-client` no longer inherits from `romexis-admin`; both use the shared `romexis-gui-runtime` independently. Payload and runtime images are build-time dependencies and are not additional services in the runtime Compose stack.
---
## Compose Architecture
Base-Image.de.md
+33 -7
@@ -1,28 +1,49 @@
**Deutsch** | [English](Base-Image)
[**Deutsch**](Base-Image.de) | [English](Base-Image)
# Base-Image
# Runtime-Basis-Images
Das Base-Image stellt wiederverwendbare Laufzeitabhängigkeiten für das Romexis-Server-Image bereit.
Die Build-Architektur verwendet getrennte wiederverwendbare Runtime-Images für Server sowie grafische Admin-/Client-Workloads. Dadurch bleiben aufwendige architekturspezifische Abhängigkeiten aus den versionsspezifischen finalen Images heraus.
Verzeichnis:
Verzeichnisse:
```text
romexis-base/
romexis-gui-runtime/
romexis-common/
```
---
## Verantwortlichkeiten
## Verantwortlichkeiten der Server-Runtime
Das Base-Image stellt Folgendes bereit:
`romexis-base-jre` stellt Folgendes bereit:
- Java-11-Laufzeit
- JavaFX-/OpenJFX-Unterstützung
- Microsoft-SQL-Server-Kommandozeilenwerkzeuge
- Firebird-Clientbibliotheken und -Werkzeuge
- gemeinsame Betriebssystempakete
- native Chilkat-Bibliothek und JAR
- `RomexisPropertyAgent.jar`
- Sicherheitsaktualisierungen
Die aufwendigen Native-/Java-Artefakte werden dadurch einmal pro Architektur statt einmal pro Romexis-Version gebaut.
---
## Verantwortlichkeiten der GUI-Runtime
`romexis-gui-runtime` wird gemeinsam von `romexis-admin` und `romexis-client` verwendet. Sie stellt bereit:
- Java 17 und OpenJFX
- Xvfb, Openbox und xcompmgr
- x11vnc und noVNC/websockify
- GTK-/Mesa-/OpenGL-Abhängigkeiten
- Chilkat und `RomexisPropertyAgent.jar`
- die aus `romexis-common/dxservice_dummy.c` gebaute DxService-Kompatibilitätsbibliothek
Admin und Client installieren bzw. kompilieren diese Abhängigkeiten daher nicht erneut für jede Romexis-Version.
---
## Architekturspezifische Tags
@@ -30,9 +51,14 @@ Das Base-Image stellt Folgendes bereit:
```text
romexis-base-jre:11-amd64
romexis-base-jre:11-arm64
romexis-base-jre:11
romexis-gui-runtime:1-amd64
romexis-gui-runtime:1-arm64
romexis-gui-runtime:1
```
Das Base-Image ist architekturspezifisch, weil es native Laufzeitpakete enthält.
Die Runtime-Images sind architekturspezifisch, weil sie native Laufzeitpakete enthalten. Die Tags ohne Architektur-Suffix sind Multi-Architektur-Manifeste, die erst nach erfolgreichen Builds beider Architekturen veröffentlicht werden.
---
Base-Image.md
+32 -6
@@ -1,28 +1,49 @@
[Deutsch](Base-Image.de) | **English**
# Base Image
# Runtime Base Images
The base image provides reusable runtime dependencies for the Romexis Server image.
The build architecture uses separate reusable runtime images for the server and graphical Admin/Client workloads. This keeps expensive architecture-specific dependencies out of the version-specific final images.
Directory:
Directories:
```text
romexis-base/
romexis-gui-runtime/
romexis-common/
```
---
## Responsibilities
## Server Runtime Responsibilities
The base image provides:
`romexis-base-jre` provides:
- Java 11 runtime
- JavaFX/OpenJFX support
- Microsoft SQL Server command-line tools
- Firebird client libraries and tools
- common OS packages
- Chilkat native library and JAR
- `RomexisPropertyAgent.jar`
- security updates
The expensive native/Java artifacts are therefore built once per architecture instead of once per Romexis version.
---
## GUI Runtime Responsibilities
`romexis-gui-runtime` is shared by `romexis-admin` and `romexis-client`. It provides:
- Java 17 and OpenJFX
- Xvfb, Openbox and xcompmgr
- x11vnc and noVNC/websockify
- GTK/Mesa/OpenGL dependencies
- Chilkat and `RomexisPropertyAgent.jar`
- the DxService compatibility library built from `romexis-common/dxservice_dummy.c`
Admin and Client therefore do not repeatedly install or compile these dependencies for every Romexis version.
---
## Architecture-Specific Tags
@@ -30,9 +51,14 @@ The base image provides:
```text
romexis-base-jre:11-amd64
romexis-base-jre:11-arm64
romexis-base-jre:11
romexis-gui-runtime:1-amd64
romexis-gui-runtime:1-arm64
romexis-gui-runtime:1
```
The base image is architecture-specific because it contains native runtime packages.
The runtime images are architecture-specific because they contain native runtime packages. The unsuffixed tags are multi-architecture manifests published only after both architecture builds succeed.
---
Build-System.de.md
+50 -31
@@ -5,19 +5,20 @@
Das Build-System ist in unabhängige Schichten und Service-Images aufgeteilt.
```text
romexis-payload
|
+--> romexis-server
+--> romexis-admin
+--> romexis-mromexis-app
^
|
romexis-base-jre
romexis-payload ----------------+--> romexis-server
+--> romexis-admin
+--> romexis-mromexis-app
romexis-firebird-payload
|
v
romexis-server
romexis-client-payload ------------> romexis-client
romexis-base-jre ------------------> romexis-server
romexis-gui-runtime -----------+--> romexis-admin
+--> romexis-client
romexis-firebird-payload ----------> romexis-server
romexis-common -> server/gui runtime build sources
```
---
@@ -38,6 +39,10 @@ Er erzeugt:
Er stellt außerdem Dateien bereit, die von anderen Service-Images verwendet werden, einschließlich Admin-Dateien und, sofern verfügbar, der WAR-Datei der mRomexis Web App.
### Client-Payload-Build
Das Client-Payload wird aus demselben Windows-Installer mit einer separaten Copy-Map extrahiert. Es erzeugt die für das eigenständige Image `romexis-client` benötigten Dateien und wird als `romexis-client-payload:<version>` versioniert.
### Firebird-Payload-Build
Der Firebird-Payload-Build extrahiert das Datenbankpaket des macOS-Installers.
@@ -51,15 +56,25 @@ Er erzeugt:
/opt/romexis-firebird-db/templates
```
### Base-Image-Build
### Server-Runtime-Build
Das Base-Image stellt wiederverwendbare Runtime-Abhängigkeiten bereit:
`romexis-base-jre` stellt wiederverwendbare Server-Runtime-Abhängigkeiten bereit:
- Java 11
- JavaFX/OpenJFX
- SQL-Server-Werkzeuge
- Firebird-Clientbibliotheken und -Werkzeuge
- Betriebssystemabhängigkeiten
- Chilkat
- Java Property Agent
### GUI-Runtime-Build
`romexis-gui-runtime` enthält den von Admin und Client gemeinsam verwendeten architekturspezifischen Grafik-Stack: Java 17/OpenJFX, X11/noVNC, Mesa/GTK, Chilkat, PropertyAgent und die DxService-Kompatibilitätsbibliothek.
### Gemeinsame Runtime-Quellen
`romexis-common/` ist der zentrale Quellort für `RomexisPropertyAgent.java`, die Chilkat-Patch-Quelle und `dxservice_dummy.c`. Diese Quellen werden in die passenden Runtime-Images kompiliert, statt in Verzeichnissen finaler Images dupliziert zu werden.
### Server-Image-Build
@@ -68,14 +83,12 @@ Das finale Server-Image importiert:
- `/opt/romexis` aus `romexis-payload`
- `/opt/romexis-mssql-db` aus `romexis-payload`
- `/opt/romexis-firebird-db` aus `romexis-firebird-payload`
- die Basis-Runtime aus `romexis-base-jre`
- die native Chilkat-Bibliothek
- den Java Property Agent
- die Server-Runtime aus `romexis-base-jre`
- Runtime-Hilfsskripte
### Admin-Image-Build
Das Admin-Image importiert die Romexis-Admin-Dateien aus der Payload und ergänzt eine browserzugängliche X11-/noVNC-Runtime.
Das Admin-Image importiert die Romexis-Admin-Dateien aus der Payload und kombiniert sie mit der gemeinsamen browserzugänglichen `romexis-gui-runtime`.
Wichtige Runtime-Komponenten:
@@ -88,6 +101,10 @@ noVNC/websockify
JavaFX
```
### Client-Image-Build
Das finale Client-Image kombiniert `romexis-client-payload` mit `romexis-gui-runtime` und Client-spezifischen Start-/Testskripten. Es erbt nicht mehr vom Admin-Image.
### Build der mRomexis Web App
Das Image der mRomexis Web App kopiert:
@@ -131,37 +148,39 @@ Windows PowerShell:
Einzelne Image-Gruppen bauen:
```bash
./scripts/build-local.sh base server
./scripts/build-local.sh admin mromexis
./scripts/build-local.sh migration
./scripts/build-local.sh server-runtime server
./scripts/build-local.sh gui-runtime admin client
./scripts/build-local.sh migration control
```
---
## Beispiele für manuelle Docker-Builds
## Beispiele für manuelle Builds
Payload bauen:
Die Hilfsskripte sind der unterstützte manuelle Einstiegspunkt, weil sie die benötigten Runtime-/Payload-Abhängigkeitskontexte konsistent erzeugen.
Wiederverwendbare Runtimes bauen:
```bash
docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-payload:6.5.3.444.203 --load ./romexis-payload
./scripts/build-local.sh server-runtime gui-runtime
```
Server-Image bauen:
Payloads explizit bauen:
```bash
docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-server:6.5.3.444.203-amd64 --load ./romexis
./scripts/build-local.sh payload client-payload firebird-payload
```
Admin-Image bauen:
Finale Anwendungs-Images bauen:
```bash
docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-admin:6.5.3.444.203-amd64 --load ./romexis-admin
./scripts/build-local.sh server admin client mromexis
```
mRomexis Web App bauen:
Für Windows PowerShell stehen dieselben Targets bereit:
```bash
docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-mromexis-app:6.5.3.444.203-amd64 --load ./romexis-mromexis-app
```powershell
.\scripts\build-local.ps1 -Targets server-runtime,gui-runtime,server,admin,client
```
---
Build-System.md
+50 -31
@@ -5,19 +5,20 @@
The build system is split into independent layers and service images.
```text
romexis-payload
|
+--> romexis-server
+--> romexis-admin
+--> romexis-mromexis-app
^
|
romexis-base-jre
romexis-payload ----------------+--> romexis-server
+--> romexis-admin
+--> romexis-mromexis-app
romexis-firebird-payload
|
v
romexis-server
romexis-client-payload ------------> romexis-client
romexis-base-jre ------------------> romexis-server
romexis-gui-runtime -----------+--> romexis-admin
+--> romexis-client
romexis-firebird-payload ----------> romexis-server
romexis-common -> server/gui runtime build sources
```
---
@@ -38,6 +39,10 @@ It produces:
It also provides files consumed by other service images, including Admin files and the mRomexis Web App WAR when available.
### Client payload build
The Client payload is extracted from the same Windows installer with a separate copy map. It produces the files required by the standalone `romexis-client` image and is versioned as `romexis-client-payload:<version>`.
### Firebird payload build
The Firebird payload build extracts the macOS installer database package.
@@ -51,15 +56,25 @@ It produces:
/opt/romexis-firebird-db/templates
```
### Base image build
### Server runtime build
The base image provides reusable runtime dependencies:
`romexis-base-jre` provides reusable server runtime dependencies:
- Java 11
- JavaFX/OpenJFX
- SQL Server tools
- Firebird client libraries and tools
- OS dependencies
- Chilkat
- Java property agent
### GUI runtime build
`romexis-gui-runtime` contains the architecture-specific graphical stack shared by Admin and Client: Java 17/OpenJFX, X11/noVNC, Mesa/GTK, Chilkat, PropertyAgent and the DxService compatibility library.
### Shared runtime sources
`romexis-common/` is the single source location for `RomexisPropertyAgent.java`, the Chilkat patch source and `dxservice_dummy.c`. These sources are compiled into the appropriate runtime images instead of being duplicated in final image directories.
### Server image build
@@ -68,14 +83,12 @@ The final server image imports:
- `/opt/romexis` from `romexis-payload`
- `/opt/romexis-mssql-db` from `romexis-payload`
- `/opt/romexis-firebird-db` from `romexis-firebird-payload`
- base runtime from `romexis-base-jre`
- Chilkat native library
- Java property agent
- server runtime from `romexis-base-jre`
- runtime helper scripts
### Admin image build
The Admin image imports Romexis Admin files from the payload and adds a browser-accessible X11/noVNC runtime.
The Admin image imports Romexis Admin files from the payload and combines them with the shared browser-accessible `romexis-gui-runtime`.
Important runtime components:
@@ -88,6 +101,10 @@ noVNC/websockify
JavaFX
```
### Client image build
The final Client image combines `romexis-client-payload` with `romexis-gui-runtime` and Client-specific startup/test scripts. It no longer inherits from the Admin image.
### mRomexis Web App build
The mRomexis Web App image copies:
@@ -131,37 +148,39 @@ Windows PowerShell:
Build individual image groups:
```bash
./scripts/build-local.sh base server
./scripts/build-local.sh admin mromexis
./scripts/build-local.sh migration
./scripts/build-local.sh server-runtime server
./scripts/build-local.sh gui-runtime admin client
./scripts/build-local.sh migration control
```
---
## Manual Docker Build Examples
## Manual Build Examples
Build payload:
The helper scripts are the supported manual entry point because they create the required runtime/payload dependency contexts consistently.
Build reusable runtimes:
```bash
docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-payload:6.5.3.444.203 --load ./romexis-payload
./scripts/build-local.sh server-runtime gui-runtime
```
Build server image:
Build payloads explicitly:
```bash
docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-server:6.5.3.444.203-amd64 --load ./romexis
./scripts/build-local.sh payload client-payload firebird-payload
```
Build Admin image:
Build final application images:
```bash
docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-admin:6.5.3.444.203-amd64 --load ./romexis-admin
./scripts/build-local.sh server admin client mromexis
```
Build mRomexis Web App:
For Windows PowerShell the same targets are available:
```bash
docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-mromexis-app:6.5.3.444.203-amd64 --load ./romexis-mromexis-app
```powershell
.\scripts\build-local.ps1 -Targets server-runtime,gui-runtime,server,admin,client
```
---
CI-CD-Pipeline.de.md
+82 -33
@@ -11,21 +11,43 @@ Das Projekt verwendet Drone CI, um Images zu bauen und in der Gitea-Container-Re
Die Pipeline baut:
```text
romexis-payload
romexis-firebird-payload
romexis-base-jre:11-amd64
romexis-base-jre:11-arm64
romexis-server:<version>-amd64
romexis-server:<version>-arm64
romexis-admin:<version>-amd64
romexis-admin:<version>-arm64
romexis-mromexis-app:<version>-amd64
romexis-mromexis-app:<version>-arm64
romexis-migration-service:amd64
romexis-migration-service:arm64
multiarch manifests
romexis-payload:<version>
romexis-client-payload:<version>
romexis-firebird-payload:latest
romexis-base-jre:11-amd64 / 11-arm64
romexis-gui-runtime:1-amd64 / 1-arm64
romexis-server:<version>-amd64 / -arm64
romexis-admin:<version>-amd64 / -arm64
romexis-client:<version>-amd64 / -arm64
romexis-mromexis-app:<version>-amd64 / -arm64
romexis-migration-service:amd64 / arm64
romexis-control-agent:amd64 / arm64
public multiarch manifests
```
## Pipeline-Graph und Parallelität
Der Build ist in fünf voneinander abhängige Drone-Pipelines aufgeteilt:
```text
quality-gate
|
v
build-romexis-payload
|
+-------------------+
v v
build-romexis-amd64 build-romexis-arm64
| |
+---------+---------+
v
create-romexis-manifests
```
Innerhalb jeder Architektur-Pipeline können unabhängige Komponenten entsprechend ihrem Abhängigkeitsgraphen parallel laufen. Runtime-abhängige Server-/Admin-/Client-Builds warten nur auf die Runtime, die sie tatsächlich verwenden.
---
---
## Behandlung von Branch-Suffixen
@@ -40,11 +62,32 @@ Bei Feature-Branches wird der Branchname normalisiert und als Image-Suffix angeh
Dadurch können Feature-Branch-Images und -Manifeste getestet werden, ohne `main`-Images zu überschreiben.
## Änderungserkennung und Versionsmatrix
Drone bestimmt betroffene Komponenten aus dem Branch-Diff, statt für jeden Commit die vollständige Image-Matrix neu zu bauen. Feature-Branches werden gegen die Merge-Base des Ziel-/Default-Branches verglichen, damit eine frühere Änderung desselben Feature-Branches auch in späteren CI-Läufen sichtbar bleibt.
Typische Abhängigkeitsbereiche:
| Geänderter Bereich | Neu gebaute Komponenten |
|---|---|
| `romexis-base/**` oder Server-Runtime-Quellen | Server-Runtime, Server |
| `romexis-gui-runtime/**` oder GUI-Runtime-Quellen | GUI-Runtime, Admin, Client |
| `romexis/**` | Server |
| `romexis-admin/**` | Admin |
| `romexis-client/**` | Client |
| `migration-service/**` | Migration Service |
| `romexis-control-agent/**` | Control Agent |
| nur Dokumentation | keine Produktions-Images |
Normale Feature-Branches bauen nur die Standard-Romexis-Version, sofern nicht ausdrücklich ein vollständiger Matrix-Build angefordert wird.
---
---
## Payload-Buildlogik
Der Windows-Payload-Build prüft Versionsdefinitionen und Änderungen an der Kopierzuordnung.
Der Windows-Payload-Build prüft Versionsdefinitionen sowie Änderungen an den Server-/Admin- und Client-Copy-Maps. Stabile Payload-Tags werden über normale Feature-Branches hinweg wiederverwendet; geänderte Payload-Erzeugung verwendet isolierte commit-spezifische CI-Tags.
Gewünschtes Verhalten:
@@ -75,25 +118,33 @@ romexis-firebird-payload:latest
Das Server-Image verwendet das gemeinsame Firebird-Payload-Image.
## Gemeinsame Runtime-Builds und Registry-Cache
`romexis-base-jre` und `romexis-gui-runtime` werden pro Architektur einmal gebaut, wenn sich ihre Quellen ändern. BuildKit-Cache-Daten werden in getrennten Registry-Cache-Scopes gespeichert und über `--cache-from` / `--cache-to` wiederverwendet.
Dadurch werden aufwendige Paketinstallationen, Chilkat-Extraktion sowie Java-/Native-Kompilierung nicht für jede Romexis-Version wiederholt.
---
---
## Server-Build
Der Server-Build lädt:
Der Server-Build kombiniert die ausgewählte Server-Runtime, das Romexis-Payload und das Firebird-Payload über explizite BuildKit-Image-Contexts:
```text
ROMEXIS_PAYLOAD_IMAGE
ROMEXIS_FIREBIRD_PAYLOAD_IMAGE
ROMEXIS_BASE_IMAGE
romexis-server-runtime
romexis-payload
romexis-firebird-payload
```
Anschließend wird das endgültige Laufzeitimage für jede Architektur gebaut.
Wurde eine Runtime im selben CI-Lauf neu gebaut, wird direkt ihr commit-spezifischer Staging-Tag verwendet. Andernfalls wird der stabile öffentliche Runtime-Tag genutzt. Das finale Server-Image wird getrennt für jede Architektur gebaut.
---
## Admin-Build
Der Admin-Build verwendet das Romexis-Payload und baut:
Der Admin-Build verwendet die gemeinsame GUI-Runtime zusammen mit dem Romexis-Server-/Admin-Payload und baut:
```text
romexis-admin:<version>-amd64
@@ -104,6 +155,14 @@ romexis-admin:latest
Das endgültige Image enthält die grafische noVNC-Laufzeit sowie die Dateien von Romexis Admin / RomexisConfig.
## Client-Build
Der Client-Build verwendet `romexis-gui-runtime` zusammen mit `romexis-client-payload` und veröffentlicht versionierte amd64-/arm64-Images. Er ist vom Admin-Build unabhängig; eine reine Admin-Quelländerung erfordert keinen Client-Rebuild.
Zu den veröffentlichten öffentlichen Tags gehören das Versionsmanifest und `latest` für die konfigurierte Standardversion.
---
---
## mRomexis-Web-App-Build
@@ -133,9 +192,9 @@ romexis-mromexis-app:latest
## Push gegenüber Load
In CI sollte `--push` für die buildx-Ausgabe verwendet werden, wenn Images veröffentlicht werden.
In CI verwenden Architektur-Builds `--push` und schreiben ausschließlich unveränderliche `ci-<commit>-...`-Staging-Tags. Öffentliche Versions-, `latest`- und Runtime-Manifest-Tags werden während des Builds nicht verändert.
Dies vermeidet unnötiges lokales Laden von Images und kann die Worker-Zeit reduzieren.
Nach erfolgreichen amd64- und arm64-Builds erstellt bzw. ersetzt die finale Pipeline die öffentlichen Manifeste atomar mit `docker buildx imagetools create`. Ein Branch-Head-Guard verhindert, dass ein älterer langsamer Build über einen neueren Commit veröffentlicht. Dadurch bleiben bestehende öffentliche Manifeste auch während eines laufenden neuen Builds pullbar.
---
@@ -143,17 +202,7 @@ Dies vermeidet unnötiges lokales Laden von Images und kann die Worker-Zeit redu
### Build ist nach dem Leeren des Caches zu schnell
Dies kann bedeuten, dass die Pipeline den Build übersprungen hat, weil das Registry-Image bereits existiert.
Nach Protokollzeilen wie diesen suchen:
```text
already exists
Skipping rebuild
docker manifest inspect
```
Einen Neubau erzwingen, indem die Pipeline-Bedingung geändert oder die Variable für den erzwungenen Neubau gesetzt wird.
Dies bedeutet üblicherweise, dass die Änderungserkennung die Komponente als nicht betroffen eingestuft hat oder BuildKit den Großteil der Layer aus dem Registry-Cache wiederhergestellt hat. Prüfe die Prepare-/Change-Detection-Ausgabe und die Komponenten-Build-Logs, bevor du einen Rebuild erzwingst.
### `latest`-Tag nicht gefunden
CI-CD-Pipeline.md
+82 -33
@@ -11,21 +11,43 @@ The project uses Drone CI to build and publish images to the Gitea container reg
The pipeline builds:
```text
romexis-payload
romexis-firebird-payload
romexis-base-jre:11-amd64
romexis-base-jre:11-arm64
romexis-server:<version>-amd64
romexis-server:<version>-arm64
romexis-admin:<version>-amd64
romexis-admin:<version>-arm64
romexis-mromexis-app:<version>-amd64
romexis-mromexis-app:<version>-arm64
romexis-migration-service:amd64
romexis-migration-service:arm64
multiarch manifests
romexis-payload:<version>
romexis-client-payload:<version>
romexis-firebird-payload:latest
romexis-base-jre:11-amd64 / 11-arm64
romexis-gui-runtime:1-amd64 / 1-arm64
romexis-server:<version>-amd64 / -arm64
romexis-admin:<version>-amd64 / -arm64
romexis-client:<version>-amd64 / -arm64
romexis-mromexis-app:<version>-amd64 / -arm64
romexis-migration-service:amd64 / arm64
romexis-control-agent:amd64 / arm64
public multiarch manifests
```
## Pipeline Graph and Parallelism
The build is split into five dependent Drone pipelines:
```text
quality-gate
|
v
build-romexis-payload
|
+-------------------+
v v
build-romexis-amd64 build-romexis-arm64
| |
+---------+---------+
v
create-romexis-manifests
```
Within each architecture pipeline, independent components can run in parallel according to their dependency graph. Runtime-dependent Server/Admin/Client builds wait only for the runtime they actually consume.
---
---
## Branch Suffix Handling
@@ -40,11 +62,32 @@ For feature branches, the branch name is normalized and appended as an image suf
This allows feature branch images and manifests to be tested without overwriting `main` images.
## Change Detection and Version Matrix
Drone determines affected components from the branch diff instead of rebuilding the complete image matrix for every commit. Feature branches compare against the merge base of the target/default branch so an earlier change on the same feature branch remains visible to later CI runs.
Typical dependency scopes:
| Changed area | Rebuilt components |
|---|---|
| `romexis-base/**` or server runtime sources | Server runtime, Server |
| `romexis-gui-runtime/**` or GUI runtime sources | GUI runtime, Admin, Client |
| `romexis/**` | Server |
| `romexis-admin/**` | Admin |
| `romexis-client/**` | Client |
| `migration-service/**` | Migration Service |
| `romexis-control-agent/**` | Control Agent |
| documentation only | no production images |
Normal feature branches build only the default Romexis version unless a full matrix build is explicitly requested.
---
---
## Payload Build Logic
The Windows payload build checks version definitions and copy-map changes.
The Windows payload build checks version definitions and both server/admin and Client copy-map changes. Stable payload tags are reused across ordinary feature branches; changed payload generation uses isolated commit-specific CI tags.
Desired behavior:
@@ -75,25 +118,33 @@ romexis-firebird-payload:latest
The server image consumes the shared Firebird payload image.
## Shared Runtime Builds and Registry Cache
`romexis-base-jre` and `romexis-gui-runtime` are built once per architecture when their sources change. BuildKit cache data is stored in separate registry cache scopes and reused through `--cache-from` / `--cache-to`.
This prevents expensive package installation, Chilkat extraction and Java/native compilation from being repeated for every Romexis version.
---
---
## Server Build
The server build pulls:
The server build combines the selected server runtime, Romexis payload and Firebird payload through explicit BuildKit image contexts:
```text
ROMEXIS_PAYLOAD_IMAGE
ROMEXIS_FIREBIRD_PAYLOAD_IMAGE
ROMEXIS_BASE_IMAGE
romexis-server-runtime
romexis-payload
romexis-firebird-payload
```
Then builds the final runtime image for each architecture.
When a runtime was rebuilt in the same CI run, its commit-specific staging tag is consumed directly. Otherwise the stable public runtime tag is used. The final Server image is built separately for each architecture.
---
## Admin Build
The Admin build consumes the Romexis payload and builds:
The Admin build consumes the shared GUI runtime plus the Romexis server/admin payload and builds:
```text
romexis-admin:<version>-amd64
@@ -104,6 +155,14 @@ romexis-admin:latest
The final image contains the graphical noVNC runtime and Romexis Admin / RomexisConfig files.
## Client Build
The Client build consumes `romexis-gui-runtime` plus `romexis-client-payload` and publishes versioned amd64/arm64 images. It is independent from the Admin build; an Admin-only source change does not require a Client rebuild.
Published public tags include the version manifest and `latest` for the configured default version.
---
---
## mRomexis Web App Build
@@ -133,9 +192,9 @@ romexis-mromexis-app:latest
## Push vs Load
In CI, use `--push` for buildx output when publishing images.
In CI, architecture builds use `--push` and write only immutable `ci-<commit>-...` staging tags. Public version, `latest` and runtime manifest tags are not modified during the build.
This avoids unnecessary local image loading and can reduce worker time.
After amd64 and arm64 succeed, the final pipeline creates or replaces public manifests atomically with `docker buildx imagetools create`. A branch-head guard prevents an older, slower build from publishing over a newer commit. This also keeps existing public manifests pullable while a new build is running.
---
@@ -143,17 +202,7 @@ This avoids unnecessary local image loading and can reduce worker time.
### Build is too fast after cache cleanup
This may mean the pipeline skipped the build because the registry image already exists.
Look for log lines like:
```text
already exists
Skipping rebuild
docker manifest inspect
```
Force rebuild by changing the pipeline condition or setting the force rebuild variable.
This usually means change detection decided that the component is unaffected, or BuildKit restored most layers from the registry cache. Check the prepare/change-detection output and the component build logs before forcing a rebuild.
### latest tag not found
Container-Images.de.md
+82 -1
@@ -10,12 +10,17 @@ Images werden in dem vom Projekt verwendeten Namespace der Gitea-Paket-Registry
```text
gitea.buchhorster.de/planmeca/romexis-payload:<version>
gitea.buchhorster.de/planmeca/romexis-client-payload:<version>
gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest
gitea.buchhorster.de/planmeca/romexis-base-jre:11-amd64
gitea.buchhorster.de/planmeca/romexis-base-jre:11-arm64
gitea.buchhorster.de/planmeca/romexis-base-jre:11
gitea.buchhorster.de/planmeca/romexis-gui-runtime:1-amd64
gitea.buchhorster.de/planmeca/romexis-gui-runtime:1-arm64
gitea.buchhorster.de/planmeca/romexis-gui-runtime:1
gitea.buchhorster.de/planmeca/romexis-server:<version>-amd64
gitea.buchhorster.de/planmeca/romexis-server:<version>-arm64
gitea.buchhorster.de/planmeca/romexis-server:<version>
@@ -25,6 +30,11 @@ gitea.buchhorster.de/planmeca/romexis-admin:<version>-arm64
gitea.buchhorster.de/planmeca/romexis-admin:<version>
gitea.buchhorster.de/planmeca/romexis-admin:latest
gitea.buchhorster.de/planmeca/romexis-client:<version>-amd64
gitea.buchhorster.de/planmeca/romexis-client:<version>-arm64
gitea.buchhorster.de/planmeca/romexis-client:<version>
gitea.buchhorster.de/planmeca/romexis-client:latest
gitea.buchhorster.de/planmeca/romexis-mromexis-app:<version>-amd64
gitea.buchhorster.de/planmeca/romexis-mromexis-app:<version>-arm64
gitea.buchhorster.de/planmeca/romexis-mromexis-app:<version>
@@ -33,6 +43,10 @@ gitea.buchhorster.de/planmeca/romexis-mromexis-app:latest
gitea.buchhorster.de/planmeca/romexis-migration-service:amd64
gitea.buchhorster.de/planmeca/romexis-migration-service:arm64
gitea.buchhorster.de/planmeca/romexis-migration-service:latest
gitea.buchhorster.de/planmeca/romexis-control-agent:amd64
gitea.buchhorster.de/planmeca/romexis-control-agent:arm64
gitea.buchhorster.de/planmeca/romexis-control-agent:latest
```
---
@@ -47,6 +61,14 @@ Das Windows-Payload-Image wird mit der Romexis-Version versioniert und ist archi
romexis-payload:6.5.3.444.203
```
### Client-Payload-Image
Das Client-Payload wird unabhängig vom finalen Client-Image versioniert, verwendet aber dieselbe Romexis-Version:
```text
romexis-client-payload:6.5.3.444.203
```
### Base-Image
Base-Images sind architekturspezifisch und werden zusätzlich als Manifest veröffentlicht:
@@ -57,6 +79,16 @@ romexis-base-jre:11-arm64
romexis-base-jre:11
```
### GUI-Runtime-Image
Admin und Client verwenden eine gemeinsame architekturspezifische GUI-Runtime, die ebenfalls als Multi-Architektur-Manifest veröffentlicht wird:
```text
romexis-gui-runtime:1-amd64
romexis-gui-runtime:1-arm64
romexis-gui-runtime:1
```
### Server-Image
Server-Images sind architekturspezifisch und werden als Multi-Architektur-Manifest veröffentlicht:
@@ -78,6 +110,17 @@ romexis-admin:<version>
romexis-admin:latest
```
### Client-Image
Der Client ist ein eigenständiges finales Image und erbt nicht vom Admin:
```text
romexis-client:<version>-amd64
romexis-client:<version>-arm64
romexis-client:<version>
romexis-client:latest
```
### mRomexis-Web-App-Image
Das mRomexis-Web-App-Image wird mit der Romexis-Version versioniert:
@@ -97,6 +140,22 @@ Es kann nur für Romexis-Versionen gebaut werden, die Folgendes enthalten:
Dies wird für Romexis 6.5.3 und neuer erwartet.
### Migration- und Control-Agent-Images
Diese Dienste sind von der Romexis-Installer-Versionsmatrix unabhängig und veröffentlichen Architektur-Aliase sowie ein `latest`-Multi-Architektur-Manifest:
```text
romexis-migration-service:amd64
romexis-migration-service:arm64
romexis-migration-service:latest
romexis-control-agent:amd64
romexis-control-agent:arm64
romexis-control-agent:latest
```
---
---
## Branch-Image-Suffixe
@@ -119,7 +178,23 @@ Beispiel für ein aufgelöstes Image:
gitea.buchhorster.de/planmeca/romexis-server:6.5.3.444.203-feature-romexis-admin
```
Dies verhindert, dass Feature-Branch-Builds Laufzeitimages von `main` überschreiben oder mit ihnen verwechselt werden.
Dies verhindert, dass Feature-Branch-Builds Laufzeitimages von `main` überschreiben oder mit ihnen verwechselt werden. Stabile versionierte Payloads werden normalerweise ohne Branch-Suffix wiederverwendet; nur Branches mit Änderungen an der Payload-Erzeugung erstellen isolierte commit-spezifische CI-Payload-Tags.
## CI-Staging-Tags und Build-Cache
Drone baut nicht direkt in öffentliche Runtime-Tags. Architektur-Builds verwenden zunächst unveränderliche commit-spezifische Staging-Tags, zum Beispiel:
```text
romexis-base-jre:ci-<commit>-amd64
romexis-gui-runtime:ci-<commit>-arm64
romexis-server:ci-<commit>-<version>-amd64
romexis-admin:ci-<commit>-<version>-arm64
romexis-client:ci-<commit>-<version>-amd64
```
Erst nachdem beide Architekturen erfolgreich sind, werden öffentliche Manifeste mit `docker buildx imagetools create` aktualisiert. Separate Registry-Einträge `romexis-buildcache:*` sind BuildKit-Caches und keine Runtime-Images.
---
---
@@ -137,6 +212,12 @@ Admin-Image:
docker pull gitea.buchhorster.de/planmeca/romexis-admin:latest
```
Client-Image:
```bash
docker pull gitea.buchhorster.de/planmeca/romexis-client:latest
```
mRomexis-Web-App-Image:
```bash
Container-Images.md
+82 -1
@@ -10,12 +10,17 @@ Images are published to the Gitea package registry namespace used by the project
```text
gitea.buchhorster.de/planmeca/romexis-payload:<version>
gitea.buchhorster.de/planmeca/romexis-client-payload:<version>
gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest
gitea.buchhorster.de/planmeca/romexis-base-jre:11-amd64
gitea.buchhorster.de/planmeca/romexis-base-jre:11-arm64
gitea.buchhorster.de/planmeca/romexis-base-jre:11
gitea.buchhorster.de/planmeca/romexis-gui-runtime:1-amd64
gitea.buchhorster.de/planmeca/romexis-gui-runtime:1-arm64
gitea.buchhorster.de/planmeca/romexis-gui-runtime:1
gitea.buchhorster.de/planmeca/romexis-server:<version>-amd64
gitea.buchhorster.de/planmeca/romexis-server:<version>-arm64
gitea.buchhorster.de/planmeca/romexis-server:<version>
@@ -25,6 +30,11 @@ gitea.buchhorster.de/planmeca/romexis-admin:<version>-arm64
gitea.buchhorster.de/planmeca/romexis-admin:<version>
gitea.buchhorster.de/planmeca/romexis-admin:latest
gitea.buchhorster.de/planmeca/romexis-client:<version>-amd64
gitea.buchhorster.de/planmeca/romexis-client:<version>-arm64
gitea.buchhorster.de/planmeca/romexis-client:<version>
gitea.buchhorster.de/planmeca/romexis-client:latest
gitea.buchhorster.de/planmeca/romexis-mromexis-app:<version>-amd64
gitea.buchhorster.de/planmeca/romexis-mromexis-app:<version>-arm64
gitea.buchhorster.de/planmeca/romexis-mromexis-app:<version>
@@ -33,6 +43,10 @@ gitea.buchhorster.de/planmeca/romexis-mromexis-app:latest
gitea.buchhorster.de/planmeca/romexis-migration-service:amd64
gitea.buchhorster.de/planmeca/romexis-migration-service:arm64
gitea.buchhorster.de/planmeca/romexis-migration-service:latest
gitea.buchhorster.de/planmeca/romexis-control-agent:amd64
gitea.buchhorster.de/planmeca/romexis-control-agent:arm64
gitea.buchhorster.de/planmeca/romexis-control-agent:latest
```
---
@@ -47,6 +61,14 @@ The Windows payload image is versioned by Romexis version and is architecture-in
romexis-payload:6.5.3.444.203
```
### Client payload image
The Client payload is versioned independently from the final Client image but uses the same Romexis version:
```text
romexis-client-payload:6.5.3.444.203
```
### Base image
Base images are architecture-specific and also published as a manifest:
@@ -57,6 +79,16 @@ romexis-base-jre:11-arm64
romexis-base-jre:11
```
### GUI runtime image
Admin and Client share an architecture-specific GUI runtime that is also published as a multi-architecture manifest:
```text
romexis-gui-runtime:1-amd64
romexis-gui-runtime:1-arm64
romexis-gui-runtime:1
```
### Server image
Server images are architecture-specific and published as a multi-architecture manifest:
@@ -78,6 +110,17 @@ romexis-admin:<version>
romexis-admin:latest
```
### Client image
The Client is a standalone final image and does not inherit from Admin:
```text
romexis-client:<version>-amd64
romexis-client:<version>-arm64
romexis-client:<version>
romexis-client:latest
```
### mRomexis Web App image
The mRomexis Web App image is versioned by Romexis version:
@@ -97,6 +140,22 @@ It can only be built for Romexis versions that contain:
This is expected for Romexis 6.5.3 and newer.
### Migration and Control Agent images
These services are independent from the Romexis installer version matrix and publish architecture aliases plus a `latest` multi-architecture manifest:
```text
romexis-migration-service:amd64
romexis-migration-service:arm64
romexis-migration-service:latest
romexis-control-agent:amd64
romexis-control-agent:arm64
romexis-control-agent:latest
```
---
---
## Branch Image Suffixes
@@ -119,7 +178,23 @@ Example resolved image:
gitea.buchhorster.de/planmeca/romexis-server:6.5.3.444.203-feature-romexis-admin
```
This prevents feature branch builds from overwriting or being confused with `main` runtime images.
This prevents feature branch builds from overwriting or being confused with `main` runtime images. Stable versioned payloads are normally reused without a branch suffix; only branches that change payload generation create isolated commit-specific CI payload tags.
## CI Staging Tags and Build Cache
Drone does not build directly into public runtime tags. Architecture builds first use immutable commit-specific staging tags, for example:
```text
romexis-base-jre:ci-<commit>-amd64
romexis-gui-runtime:ci-<commit>-arm64
romexis-server:ci-<commit>-<version>-amd64
romexis-admin:ci-<commit>-<version>-arm64
romexis-client:ci-<commit>-<version>-amd64
```
Only after both architectures succeed are public manifests updated with `docker buildx imagetools create`. Separate `romexis-buildcache:*` registry entries are BuildKit caches and are not runtime images.
---
---
@@ -137,6 +212,12 @@ Admin image:
docker pull gitea.buchhorster.de/planmeca/romexis-admin:latest
```
Client image:
```bash
docker pull gitea.buchhorster.de/planmeca/romexis-client:latest
```
mRomexis Web App image:
```bash
Developer-Guide.de.md
+45 -5
@@ -9,11 +9,20 @@ Diese Seite beschreibt die interne Projektstruktur und den Entwicklungsworkflow.
## Hauptverzeichnisse des Projekts
```text
romexis-common/
Shared Java agent, patches and native helper sources.
romexis-base/
Runtime base image.
Shared Romexis Server runtime image.
romexis-gui-runtime/
Shared GUI runtime for Romexis Admin and Client.
romexis-payload/
Windows installer payload extraction.
Windows installer payload extraction for Server/Admin/mRomexis.
romexis-client-payload/
Version-specific Romexis Client payload image.
romexis-firebird-payload/
macOS Firebird SQL payload extraction.
@@ -21,12 +30,27 @@ romexis-firebird-payload/
romexis/
Final Romexis Server image.
romexis-admin/
Final Romexis Admin image.
romexis-client/
Final standalone Romexis Client image.
romexis-mromexis-app/
Final mRomexis Web App image.
romexis-control-agent/
Restricted container control API.
migration-service/
Migration Web UI, REST API, SFTP and restore orchestration.
migration-client/
Source-side migration helper client.
scripts/
Local and CI build helpers.
docs/
Extended markdown documentation.
```
@@ -36,15 +60,31 @@ docs/
## Entwicklungsgrundsätze
- Proprietäre Binärdateien aus Git fernhalten.
- Installerextraktion in Payload-Images belassen.
- Laufzeitabhängigkeiten im Base-Image belassen.
- Das endgültige Server-Image auf Zusammenbau und Laufzeitlogik konzentrieren.
- Versionsabhängige Installerextraktion in Payload-Images belassen.
- Aufwendige architekturabhängige Abhängigkeiten in gemeinsamen Runtime-Images belassen.
- Gemeinsame Agent-, Patch- und native Hilfsquellen in `romexis-common/` pflegen.
- Die finalen Server-, Admin- und Client-Images auf Zusammenbau und Laufzeitlogik konzentrieren.
- Romexis Admin und Romexis Client als unabhängige finale Images auf Basis derselben GUI-Runtime halten.
- MSSQL- und Firebird-Initialisierung getrennt halten.
- Das Wrapper-Skript ausschließlich für das Backend-Routing verwenden.
- Explizite Validierung gegenüber still erzeugten, unvollständigen Images bevorzugen.
---
## Build-Abhängigkeitsmodell
Der Build ist bewusst in drei Ebenen aufgeteilt:
1. **Payload-Images** enthalten versionsabhängige Inhalte aus dem Romexis-Installer.
2. **Runtime-Images** enthalten wiederverwendbare architekturabhängige Betriebssystem- und Bibliotheksabhängigkeiten.
3. **Finale Images** kombinieren Payload und Runtime mit den komponentenspezifischen Skripten.
Dadurch bleiben sowohl die umfangreiche Installerextraktion als auch die aufwendige Runtime-Vorbereitung über Server-, Admin- und Client-Builds hinweg wiederverwendbar. Reine Payload- und Runtime-Build-Images sind keine zusätzlichen Laufzeitdienste in Docker Compose.
Für lokale Entwicklung werden `scripts/build-local.sh` oder `scripts/build-local.ps1` verwendet. Drone nutzt dasselbe Abhängigkeitsmodell mit unveränderlichen commitbezogenen Staging-Tags und Registry-basierten BuildKit-Caches.
---
## Datenbankinitialisierungsskripte
```text
Developer-Guide.md
+45 -5
@@ -9,11 +9,20 @@ This page describes the internal project structure and development workflow.
## Main Project Directories
```text
romexis-common/
Shared Java agent, patches and native helper sources.
romexis-base/
Runtime base image.
Shared Romexis Server runtime image.
romexis-gui-runtime/
Shared GUI runtime for Romexis Admin and Client.
romexis-payload/
Windows installer payload extraction.
Windows installer payload extraction for Server/Admin/mRomexis.
romexis-client-payload/
Version-specific Romexis Client payload image.
romexis-firebird-payload/
macOS Firebird SQL payload extraction.
@@ -21,12 +30,27 @@ romexis-firebird-payload/
romexis/
Final Romexis Server image.
romexis-admin/
Final Romexis Admin image.
romexis-client/
Final standalone Romexis Client image.
romexis-mromexis-app/
Final mRomexis Web App image.
romexis-control-agent/
Restricted container control API.
migration-service/
Migration Web UI, REST API, SFTP and restore orchestration.
migration-client/
Source-side migration helper client.
scripts/
Local and CI build helpers.
docs/
Extended markdown documentation.
```
@@ -36,15 +60,31 @@ docs/
## Development Principles
- Keep proprietary binaries out of Git.
- Keep installer extraction in payload images.
- Keep runtime dependencies in the base image.
- Keep final server image focused on assembly and runtime logic.
- Keep version-specific installer extraction in payload images.
- Keep expensive architecture-specific dependencies in shared runtime images.
- Keep common agent, patch and native helper sources in `romexis-common/`.
- Keep final Server, Admin and Client images focused on assembly and runtime logic.
- Keep Romexis Admin and Romexis Client as independent final images based on the same GUI runtime.
- Keep MSSQL and Firebird initialization separated.
- Use the wrapper script only for backend routing.
- Prefer explicit validation over silent incomplete images.
---
## Build Dependency Model
The build is intentionally split into three layers:
1. **Payload images** contain version-specific Romexis installer content.
2. **Runtime images** contain reusable architecture-specific operating-system and library dependencies.
3. **Final images** assemble payload and runtime content together with the component-specific scripts.
This keeps large installer extraction and expensive runtime preparation reusable across Server, Admin and Client builds. Build-only payload and runtime images are not additional runtime services in Docker Compose.
For local development use `scripts/build-local.sh` or `scripts/build-local.ps1`. Drone uses the same dependency model with immutable commit-specific staging tags and registry-backed BuildKit caches.
---
## Database Init Scripts
```text
Home.de.md
+22 -8
@@ -4,7 +4,7 @@
Willkommen im Wiki des Romexis-Docker-Projekts.
Dieses Wiki dokumentiert den Docker-basierten Romexis-Runtime-Stack, das Backend-spezifische Compose-Layout, die lokalen Build-Skripte, die Payload-Image-Architektur, den Romexis-Admin-Container, den mRomexis-Web-App-Container, die Datenbank-Backends, die Migrationswerkzeuge und den CI/CD-Workflow.
Dieses Wiki dokumentiert den Docker-basierten Romexis-Runtime-Stack, das Backend-spezifische Compose-Layout, die lokalen und Drone-Build-Workflows, die Payload-/Runtime-Image-Architektur, die Romexis-Server-, Admin- und Client-Container, den mRomexis-Web-App-Container, die Datenbank-Backends, die Migrationswerkzeuge und den CI/CD-Workflow.
> Dieses Projekt stellt eine reproduzierbare Docker-Umgebung für den Betrieb von Planmeca Romexis Server unter Linux, macOS oder WSL mit Windows bereit und hält den Build-Prozess dabei nahe am Layout des ursprünglichen Installers. Romexis-Anwendungsbinärdateien werden nicht im Repository gespeichert. Sie werden während des Build-Prozesses aus offiziellen Installer-Paketen extrahiert.
@@ -21,6 +21,7 @@ Dieses Wiki dokumentiert den Docker-basierten Romexis-Runtime-Stack, das Backend
| [Konfiguration](Configuration.de) | Umgebungsvariablen und Runtime-Konfiguration |
| [Container-Images](Container-Images.de) | Registry-Images, Tags, Manifeste und Branch-Suffixe |
| [Romexis Admin](Romexis-Admin.de) | Browserbasierter RomexisConfig-/Admin-Container über noVNC |
| [Romexis Client](Romexis-Client.de) | Browserbasierter Romexis-Client-Container über noVNC |
| [mRomexis Web App](mRomexis-WebApp.de) | Separater Tomcat-basierter mRomexis-Web-Frontend-Container |
| [Build-System](Build-System.de) | Payload-, Base-, Server-, Admin- und Web-App-Build-Workflow |
| [Lokale Build-Skripte](Local-Build-Scripts.de) | Lokale Build-Hilfsskripte für Linux/macOS und Windows |
@@ -37,13 +38,19 @@ Dieses Wiki dokumentiert den Docker-basierten Romexis-Runtime-Stack, das Backend
```text
romexis-payload/
Builds architecture-independent payload images from the official Windows installer.
Builds architecture-independent server/admin and client payload images from the official Windows installer.
romexis-firebird-payload/
Builds a Firebird SQL payload from the official macOS installer.
romexis-common/
Contains shared PropertyAgent, Chilkat patch and DxService compatibility sources.
romexis-base/
Builds the reusable Java 11 runtime base image.
Builds the reusable Java 11 server runtime image.
romexis-gui-runtime/
Builds the reusable Java 17/X11/noVNC GUI runtime for Admin and Client.
romexis/
Builds the final Romexis Server image.
@@ -51,17 +58,23 @@ romexis/
romexis-admin/
Builds the browser-accessible Romexis Admin / RomexisConfig container.
romexis-client/
Builds the browser-accessible Romexis Client container.
romexis-mromexis-app/
Builds the standalone mRomexis Web App container from the Romexis payload WAR.
migration-service/
Provides browser-based and API-driven migration orchestration.
romexis-control-agent/
Provides restricted container-control operations for migration and service coordination.
migration-client/
Provides the Windows migration helper client.
scripts/
Contains local build helpers such as build-local.sh and build-local.ps1.
Contains local and CI build helpers.
```
---
@@ -93,10 +106,11 @@ Das aktive Backend wird in `.env` über `DATABASE_BACKEND` und `COMPOSE_FILE` au
4. [Schnellstart](Quick-Start.de)
5. [Konfiguration](Configuration.de)
6. [Romexis Admin](Romexis-Admin.de)
7. [mRomexis Web App](mRomexis-WebApp.de)
8. [Datenbank-Backends](Database-Backends.de)
9. [Build-System](Build-System.de)
10. [Entwicklerhandbuch](Developer-Guide.de)
7. [Romexis Client](Romexis-Client.de)
8. [mRomexis Web App](mRomexis-WebApp.de)
9. [Datenbank-Backends](Database-Backends.de)
10. [Build-System](Build-System.de)
11. [Entwicklerhandbuch](Developer-Guide.de)
---
Home.md
+22 -8
@@ -4,7 +4,7 @@
Welcome to the Romexis Docker project wiki.
This wiki documents the Docker-based Romexis runtime stack, the backend-specific Compose layout, the local build scripts, the payload image architecture, the Romexis Admin container, the mRomexis Web App container, database backends, migration tooling and CI/CD workflow.
This wiki documents the Docker-based Romexis runtime stack, the backend-specific Compose layout, the local and Drone build workflows, the payload/runtime image architecture, the Romexis Server, Admin and Client containers, the mRomexis Web App container, database backends, migration tooling and CI/CD workflow.
> This project provides a reproducible Docker environment for running Planmeca Romexis Server on Linux, macOS or WSL with Windows while keeping the build process close to the original installer layout. Romexis application binaries are not stored in the repository. They are extracted from official installer packages during the build process.
@@ -21,6 +21,7 @@ This wiki documents the Docker-based Romexis runtime stack, the backend-specific
| [Configuration](Configuration) | Environment variables and runtime configuration |
| [Container Images](Container-Images) | Registry images, tags, manifests and branch suffixes |
| [Romexis Admin](Romexis-Admin) | Browser-based RomexisConfig/Admin container via noVNC |
| [Romexis Client](Romexis-Client) | Browser-based Romexis Client container via noVNC |
| [mRomexis Web App](mRomexis-WebApp) | Separate Tomcat-based mRomexis Web frontend container |
| [Build System](Build-System) | Payload, base, server, admin and web app build workflow |
| [Local Build Scripts](Local-Build-Scripts) | Local build helper scripts for Linux/macOS and Windows |
@@ -37,13 +38,19 @@ This wiki documents the Docker-based Romexis runtime stack, the backend-specific
```text
romexis-payload/
Builds architecture-independent payload images from the official Windows installer.
Builds architecture-independent server/admin and client payload images from the official Windows installer.
romexis-firebird-payload/
Builds a Firebird SQL payload from the official macOS installer.
romexis-common/
Contains shared PropertyAgent, Chilkat patch and DxService compatibility sources.
romexis-base/
Builds the reusable Java 11 runtime base image.
Builds the reusable Java 11 server runtime image.
romexis-gui-runtime/
Builds the reusable Java 17/X11/noVNC GUI runtime for Admin and Client.
romexis/
Builds the final Romexis Server image.
@@ -51,17 +58,23 @@ romexis/
romexis-admin/
Builds the browser-accessible Romexis Admin / RomexisConfig container.
romexis-client/
Builds the browser-accessible Romexis Client container.
romexis-mromexis-app/
Builds the standalone mRomexis Web App container from the Romexis payload WAR.
migration-service/
Provides browser-based and API-driven migration orchestration.
romexis-control-agent/
Provides restricted container-control operations for migration and service coordination.
migration-client/
Provides the Windows migration helper client.
scripts/
Contains local build helpers such as build-local.sh and build-local.ps1.
Contains local and CI build helpers.
```
---
@@ -93,10 +106,11 @@ The active backend is selected in `.env` through `DATABASE_BACKEND` and `COMPOSE
4. [Quick Start](Quick-Start)
5. [Configuration](Configuration)
6. [Romexis Admin](Romexis-Admin)
7. [mRomexis Web App](mRomexis-WebApp)
8. [Database Backends](Database-Backends)
9. [Build System](Build-System)
10. [Developer Guide](Developer-Guide)
7. [Romexis Client](Romexis-Client)
8. [mRomexis Web App](mRomexis-WebApp)
9. [Database Backends](Database-Backends)
10. [Build System](Build-System)
11. [Developer Guide](Developer-Guide)
---
Local-Build-Scripts.de.md
+45 -6
@@ -40,26 +40,34 @@ Verfügbare Zielgruppen:
```text
all
base
runtimes
server-runtime
gui-runtime
payload
client-payload
firebird-payload
server
admin
client
mromexis
migration
control
manifests
```
Beispiele:
```bash
./scripts/build-local.sh base server
./scripts/build-local.sh admin mromexis
./scripts/build-local.sh migration
./scripts/build-local.sh server-runtime server
./scripts/build-local.sh gui-runtime admin client
./scripts/build-local.sh migration control
```
PowerShell-Beispiele:
```powershell
.\scripts\build-local.ps1 -Targets base,server
.\scripts\build-local.ps1 -Targets admin,mromexis
.\scripts\build-local.ps1 -Targets server-runtime,server
.\scripts\build-local.ps1 -Targets gui-runtime,admin,client
```
---
@@ -80,6 +88,11 @@ 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:
@@ -88,6 +101,14 @@ 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
@@ -104,6 +125,24 @@ ${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:
```bash
PUSH=1 ./scripts/build-local.sh manifests
```
PowerShell:
```powershell
.\scripts\build-local.ps1 -Targets manifests -Push 1
```
---
---
## Typischer Workflow
Local-Build-Scripts.md
+45 -6
@@ -40,26 +40,34 @@ Available target groups:
```text
all
base
runtimes
server-runtime
gui-runtime
payload
client-payload
firebird-payload
server
admin
client
mromexis
migration
control
manifests
```
Examples:
```bash
./scripts/build-local.sh base server
./scripts/build-local.sh admin mromexis
./scripts/build-local.sh migration
./scripts/build-local.sh server-runtime server
./scripts/build-local.sh gui-runtime admin client
./scripts/build-local.sh migration control
```
PowerShell examples:
```powershell
.\scripts\build-local.ps1 -Targets base,server
.\scripts\build-local.ps1 -Targets admin,mromexis
.\scripts\build-local.ps1 -Targets server-runtime,server
.\scripts\build-local.ps1 -Targets gui-runtime,admin,client
```
---
@@ -80,6 +88,11 @@ 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
```
For feature branches:
@@ -88,6 +101,14 @@ For feature branches:
IMAGE_SUFFIX=-feature-romexis-admin
```
## Dependency Resolution and Local Aliases
Before building a final image, the scripts ensure that required payload images are available: an existing local image is reused, otherwise the registry is tried, and if the image is still unavailable it is built from the local project sources.
For `PUSH=0`, locally built runtime/payload dependencies are additionally tagged with isolated `romexis-local/...` aliases. These aliases prevent BuildKit from resolving an older registry image that happens to have the same public tag. The aliases are build-only implementation details and are not published.
---
---
## Relationship to Runtime Compose
@@ -104,6 +125,24 @@ ${REGISTRY}/${MROMEXIS_WEBAPP_IMAGE}:${ROMEXIS_VERSION}${IMAGE_SUFFIX}
This allows the same `.env` to be used for local builds and runtime startup.
## Safe Push and Manifest Publication
A local single-architecture build with `PUSH=1` publishes only the architecture tag, for example `romexis-server:<version>-amd64`. It does not replace the public multi-architecture tag.
After both architectures have been pushed, publish manifests explicitly:
```bash
PUSH=1 ./scripts/build-local.sh manifests
```
PowerShell:
```powershell
.\scripts\build-local.ps1 -Targets manifests -Push 1
```
---
---
## Typical Workflow
Payload-Images.de.md
+27
@@ -33,6 +33,20 @@ Ausgabevertrag:
Das Payload darf keine architekturspezifischen Laufzeitbibliotheken wie Chilkat enthalten.
## Client-Payload
Derselbe Windows-Installer wird zusätzlich verwendet, um ein separates architekturunabhängiges Client-Payload zu bauen:
```text
romexis-client-payload:<version>
```
Die Extraktion wird über `romexis-payload/romexis-client-copy-map.tsv` gesteuert. Durch das separate Client-Payload kann das finale Image `romexis-client` unabhängig vom Admin-Image gebaut werden.
Server-/Admin-Payload und Client-Payload sind normalerweise stabile, versionierte Eingaben und werden über Feature-Branches hinweg wiederverwendet, statt bei jedem Commit erneut extrahiert zu werden.
---
---
## Versionsdatei
@@ -114,6 +128,19 @@ Wichtige Dateien:
/opt/romexis-firebird-db/templates/romexis_new.fdb
```
## CI-Rebuild- und Staging-Verhalten
Drone baut Payloads nur neu, wenn eine neue Romexis-Version oder eine Änderung an Extraktion/Copy-Maps dies erfordert. Ändert ein Feature-Branch die Payload-Erzeugung, werden isolierte commit-spezifische Tags verwendet, zum Beispiel:
```text
romexis-payload:ci-<commit>-<version>
romexis-client-payload:ci-<commit>-<version>
```
Dadurch ersetzen experimentelle Extraktionsänderungen keine stabilen versionierten Payloads.
---
---
## Ein Payload-Image untersuchen
Payload-Images.md
+27
@@ -33,6 +33,20 @@ Output contract:
The payload must not contain architecture-specific runtime libraries like Chilkat.
## Client Payload
The same Windows installer is also used to build a separate architecture-independent Client payload:
```text
romexis-client-payload:<version>
```
Its extraction is controlled by `romexis-payload/romexis-client-copy-map.tsv`. Keeping Client files in a separate payload allows the final `romexis-client` image to be built independently from the Admin image.
The server/admin payload and Client payload are normally stable, versioned inputs and are reused across feature branches instead of being re-extracted for every commit.
---
---
## Version File
@@ -114,6 +128,19 @@ Important files:
/opt/romexis-firebird-db/templates/romexis_new.fdb
```
## CI Rebuild and Staging Behavior
Drone rebuilds payloads only when a new Romexis version or payload extraction/copy-map change requires it. A feature branch that changes payload generation uses isolated commit-specific tags such as:
```text
romexis-payload:ci-<commit>-<version>
romexis-client-payload:ci-<commit>-<version>
```
This prevents experimental extraction changes from replacing stable versioned payloads.
---
---
## Inspecting a Payload Image
Project-Structure.de.md
+25 -9
@@ -5,6 +5,7 @@
```text
.
├── .drone.yml
├── .dockerignore
├── .env.sample
├── docker-compose.yml
├── docker-compose.mssql.yml
@@ -16,13 +17,26 @@
├── DEVELOPERS.md
├── scripts/
│ ├── build-local.sh
│ └── build-local.ps1
│ ├── build-local.ps1
│ ├── ci-lib.sh
│ ├── ci-prepare.sh
│ ├── ci-prepare-buildx.sh
│ ├── ci-payload.sh
│ ├── ci-build-component.sh
│ └── ci-publish-manifests.sh
├── romexis-common/
│ ├── RomexisPropertyAgent.java
│ ├── dxservice_dummy.c
│ └── patches-src/
├── romexis-base/
│ └── Dockerfile
├── romexis-gui-runtime/
│ └── Dockerfile
├── romexis-payload/
│ ├── Dockerfile
│ ├── romexis-versions.env
│ ├── romexis-copy-map.tsv
│ ├── romexis-client-copy-map.tsv
│ ├── download-romexis-installer-parts.py
│ └── extract-and-copy-romexis-parts.sh
├── romexis-firebird-payload/
@@ -32,18 +46,20 @@
├── romexis/
│ ├── Dockerfile
│ ├── entrypoint.sh
│ ├── init-romexis-db.sh
│ ├── init-romexis-mssql-db.sh
│ ├── init-romexis-firebird-db.sh
│ ├── fix-keystore-alias.sh
│ └── RomexisPropertyAgent.java
│ └── database/runtime helper scripts
├── romexis-admin/
│ ├── Dockerfile
│ ├── start.sh
│ └── native helper sources
├── romexis-mromexis-app/
│ └── test.sh
├── romexis-client/
│ ├── Dockerfile
│ └── nginx.conf
│ ├── start.sh
│ └── test.sh
├── romexis-mromexis-app/
│ └── Dockerfile
├── romexis-control-agent/
│ ├── Dockerfile
│ └── app.py
├── migration-service/
│ ├── Dockerfile
│ ├── entrypoint.sh
Project-Structure.md
+25 -9
@@ -5,6 +5,7 @@
```text
.
├── .drone.yml
├── .dockerignore
├── .env.sample
├── docker-compose.yml
├── docker-compose.mssql.yml
@@ -16,13 +17,26 @@
├── DEVELOPERS.md
├── scripts/
│ ├── build-local.sh
│ └── build-local.ps1
│ ├── build-local.ps1
│ ├── ci-lib.sh
│ ├── ci-prepare.sh
│ ├── ci-prepare-buildx.sh
│ ├── ci-payload.sh
│ ├── ci-build-component.sh
│ └── ci-publish-manifests.sh
├── romexis-common/
│ ├── RomexisPropertyAgent.java
│ ├── dxservice_dummy.c
│ └── patches-src/
├── romexis-base/
│ └── Dockerfile
├── romexis-gui-runtime/
│ └── Dockerfile
├── romexis-payload/
│ ├── Dockerfile
│ ├── romexis-versions.env
│ ├── romexis-copy-map.tsv
│ ├── romexis-client-copy-map.tsv
│ ├── download-romexis-installer-parts.py
│ └── extract-and-copy-romexis-parts.sh
├── romexis-firebird-payload/
@@ -32,18 +46,20 @@
├── romexis/
│ ├── Dockerfile
│ ├── entrypoint.sh
│ ├── init-romexis-db.sh
│ ├── init-romexis-mssql-db.sh
│ ├── init-romexis-firebird-db.sh
│ ├── fix-keystore-alias.sh
│ └── RomexisPropertyAgent.java
│ └── database/runtime helper scripts
├── romexis-admin/
│ ├── Dockerfile
│ ├── start.sh
│ └── native helper sources
├── romexis-mromexis-app/
│ └── test.sh
├── romexis-client/
│ ├── Dockerfile
│ └── nginx.conf
│ ├── start.sh
│ └── test.sh
├── romexis-mromexis-app/
│ └── Dockerfile
├── romexis-control-agent/
│ ├── Dockerfile
│ └── app.py
├── migration-service/
│ ├── Dockerfile
│ ├── entrypoint.sh
Release-Process.de.md
+30 -12
@@ -12,21 +12,35 @@ Ein Release umfasst üblicherweise:
- optionale Änderungen am Migrationsdienst
- optionale Änderungen am Client
Die optimierte Build-Architektur unterscheidet zwischen versionsabhängigen Payload-Images, gemeinsamen architekturabhängigen Runtime-Images und finalen, für Anwender bestimmten Komponenten-Images. Payload- und Runtime-Images sind Build-Abhängigkeiten; reguläre Installationen verwenden weiterhin die finalen Images.
---
## Empfohlene Release-Schritte
1. Sicherstellen, dass das Repository fehlerfrei gebaut wird.
2. Verfügbarkeit der Payload-Images prüfen.
3. Base-Images für die Zielarchitekturen prüfen.
4. Server-Images für die Zielarchitekturen prüfen.
5. Multiarch-Manifeste prüfen.
6. Docker-Compose-Start testen.
7. Datenbankinitialisierung testen.
8. Start des Migrationsdienstes testen.
9. Release Notes erstellen.
10. Gitea-Release veröffentlichen.
11. Gitea-Pakete prüfen.
1. Sicherstellen, dass das Repository fehlerfrei gebaut wird und die Wiki-Tests bestehen.
2. Verfügbarkeit der Server-, Client- und Firebird-Payload-Images prüfen.
3. Server- und GUI-Runtime-Images für die Zielarchitekturen prüfen.
4. Server-, Admin-, Client- und mRomexis-Images für die Zielarchitekturen prüfen.
5. Images für Migrationsdienst und Control Agent prüfen, sofern diese betroffen sind.
6. Multiarch-Manifeste prüfen.
7. Docker-Compose-Start testen.
8. Datenbankinitialisierung testen.
9. Start des Migrationsdienstes testen.
10. Release Notes erstellen.
11. Gitea-Release veröffentlichen.
12. Gitea-Pakete prüfen.
---
## Zu prüfende Image-Ebenen
| Ebene | Images | Zweck |
|---|---|---|
| Payload | `romexis-payload`, `romexis-client-payload`, `romexis-firebird-payload` | Versionsabhängige Installer-/Datenbankinhalte |
| Runtime | `romexis-base-jre`, `romexis-gui-runtime` | Wiederverwendbare architekturabhängige Abhängigkeiten |
| Final | `romexis-server`, `romexis-admin`, `romexis-client`, `romexis-mromexis-app` | Bereitstellbare Romexis-Komponenten |
| Dienste | `romexis-migration-service`, `romexis-control-agent` | Unabhängige unterstützende Dienste |
---
@@ -43,6 +57,8 @@ Untersuchen:
docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server:<version>
```
Der öffentliche Multiarch-Tag wird erst veröffentlicht, nachdem die erforderlichen architekturspezifischen Staging-Images erfolgreich fertiggestellt wurden. Drone verwendet commitbezogene `ci-<commit>-...`-Staging-Tags und erstellt das öffentliche Manifest am Ende der Pipeline. Dadurch bleibt das vorherige öffentliche Manifest während eines laufenden Builds weiterhin pullbar.
---
## Release Notes sollten Folgendes erwähnen
@@ -54,6 +70,8 @@ docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server:<version>
- erforderliche Änderungen an Umgebungsvariablen
- bekannte Einschränkungen
Änderungen, die nur die internen Payload-/Runtime-Buildebenen betreffen, erfordern normalerweise keine Anpassung der Bereitstellung, solange die öffentlichen finalen Image-Namen, Tags und Laufzeitschnittstellen kompatibel bleiben.
---
## Gitea-Bereiche
@@ -64,6 +82,6 @@ Gitea wird wie folgt verwendet:
|---|---|
| Code | Quellcode und Dockerfiles |
| Releases | Menschenlesbare, versionierte Release Notes |
| Packages | Veröffentlichte Container-Images |
| Packages | Veröffentlichte Payload-, Runtime- und finale Container-Images |
| Wiki | Betriebs- und Entwicklerdokumentation |
| Issues | Fehler, Funktionswünsche und Planung |
Release-Process.md
+30 -12
@@ -12,21 +12,35 @@ A release usually includes:
- optional migration service changes
- optional client changes
The optimized build architecture distinguishes between version-specific payload images, shared architecture-specific runtime images and final user-facing component images. Payload and runtime images are build dependencies; final images remain the images consumed by normal deployments.
---
## Suggested Release Steps
1. Ensure the repository builds cleanly.
2. Verify payload image availability.
3. Verify base images for target architectures.
4. Verify server images for target architectures.
5. Verify multiarch manifests.
6. Test Docker Compose startup.
7. Test database initialization.
8. Test migration service startup.
9. Create release notes.
10. Publish Gitea release.
11. Verify Gitea packages.
1. Ensure the repository builds cleanly and the wiki tests pass.
2. Verify Server, Client and Firebird payload image availability.
3. Verify Server and GUI runtime images for the target architectures.
4. Verify Server, Admin, Client and mRomexis images for the target architectures.
5. Verify Migration Service and Control Agent images when affected.
6. Verify multiarch manifests.
7. Test Docker Compose startup.
8. Test database initialization.
9. Test migration service startup.
10. Create release notes.
11. Publish Gitea release.
12. Verify Gitea packages.
---
## Image Layers to Verify
| Layer | Images | Purpose |
|---|---|---|
| Payload | `romexis-payload`, `romexis-client-payload`, `romexis-firebird-payload` | Version-specific installer/database content |
| Runtime | `romexis-base-jre`, `romexis-gui-runtime` | Reusable architecture-specific dependencies |
| Final | `romexis-server`, `romexis-admin`, `romexis-client`, `romexis-mromexis-app` | Deployable Romexis components |
| Services | `romexis-migration-service`, `romexis-control-agent` | Independent supporting services |
---
@@ -43,6 +57,8 @@ Inspect:
docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server:<version>
```
The public multiarch tag is published only after the required architecture-specific staging images have completed successfully. Drone uses commit-specific `ci-<commit>-...` staging tags and creates the public manifest at the end of the pipeline, so the previous public manifest remains pullable during a running build.
---
## Release Notes Should Mention
@@ -54,6 +70,8 @@ docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server:<version>
- required environment variable changes
- known limitations
Changes that only affect internal payload/runtime build layers normally do not require deployment changes as long as the public final image names, tags and runtime interfaces remain compatible.
---
## Gitea Areas
@@ -64,6 +82,6 @@ Use Gitea as follows:
|---|---|
| Code | Source code and Dockerfiles |
| Releases | Human-readable versioned release notes |
| Packages | Published container images |
| Packages | Published payload, runtime and final container images |
| Wiki | Operational and developer documentation |
| Issues | Bugs, feature requests and planning |
Romexis-Admin.de.md
+8
@@ -24,6 +24,14 @@ Openbox und xcompmgr sind erforderlich, weil Romexis Admin Swing-/AWT-Dialoge mi
Das Openbox-Kontextmenü des Root-Desktops ist im Startskript deaktiviert, weil es in der noVNC-Laufzeit nicht nützlich ist.
## Gemeinsame GUI-Runtime
`romexis-admin` installiert den vollständigen Java-/X11-/noVNC-/Native-Stack nicht mehr selbst. Diese architekturspezifischen Abhängigkeiten werden durch `romexis-gui-runtime:1-<arch>` bereitgestellt, die ebenfalls von `romexis-client` verwendet wird.
Das finale Admin-Image ergänzt nur noch das versionsspezifische Admin-Payload, materialisiert die gemeinsamen Runtime-Artefakte im Admin-Verzeichnis und fügt die Admin-Start-/Testskripte hinzu. Admin und Client sind unabhängige finale Images; keines erbt vom jeweils anderen.
---
---
## Zugriff
Romexis-Admin.md
+8
@@ -24,6 +24,14 @@ Openbox and xcompmgr are required because Romexis Admin uses Swing/AWT dialogs w
The Openbox root desktop context menu is disabled in the startup script, because it is not useful in the noVNC runtime.
## Shared GUI Runtime
`romexis-admin` no longer installs the complete Java/X11/noVNC/native stack itself. These architecture-specific dependencies are provided by `romexis-gui-runtime:1-<arch>`, which is also used by `romexis-client`.
The final Admin image only adds the version-specific Admin payload, materializes the shared runtime artifacts in the Admin directory and adds the Admin startup/test scripts. Admin and Client are independent final images and neither inherits from the other.
---
---
## Access
Romexis-Client.de.md
+76
@@ -0,0 +1,76 @@
[**Deutsch**](Romexis-Client.de) | [English](Romexis-Client)
# Romexis Client
Der Dienst `romexis-client` stellt den Linux-Romexis-Client browserbasiert über dasselbe X11-/noVNC-Runtime-Konzept bereit, das auch der Admin-Container verwendet.
Er wird unabhängig von `romexis-admin` gebaut: Beide Images verwenden die gemeinsame `romexis-gui-runtime`, während die Client-Anwendungsdateien aus dem dedizierten Image `romexis-client-payload` stammen.
---
## Image-Abhängigkeiten
```text
romexis-client-payload:<version>
|
v
romexis-gui-runtime:1-<arch>
|
v
romexis-client:<version>-<arch>
```
Die Trennung verhindert, dass reine Admin-Änderungen einen Client-Rebuild erzwingen, und hält die große Installer-Extraktion von den architekturspezifischen GUI-Abhängigkeiten getrennt.
---
## Runtime-Komponenten
Die gemeinsame GUI-Runtime stellt bereit:
```text
Java 17
OpenJFX
Xvfb
Openbox
x11vnc
noVNC / websockify
GTK / Mesa / OpenGL dependencies
Chilkat
DxService compatibility library
```
Das finale Client-Image ergänzt das versionsspezifische Romexis-Client-Payload sowie die Client-Start- und Testskripte.
---
## Zugriff
Der Client wird über noVNC bereitgestellt. Der konkrete Host-Port wird über die Compose-Konfiguration gesteuert.
Für Logs:
```bash
docker compose logs -f romexis-client
```
Shell zur Fehleranalyse öffnen:
```bash
docker compose run --rm --entrypoint /bin/bash romexis-client
```
---
## Build und Tags
Veröffentlichte Versions-Tags folgen demselben Schema wie Server und Admin:
```text
romexis-client:<version>-amd64
romexis-client:<version>-arm64
romexis-client:<version>
romexis-client:latest
```
Zuerst werden die Architektur-Tags erstellt. Die öffentlichen Multi-Architektur-Tags werden erst veröffentlicht, wenn beide Architekturen erfolgreich abgeschlossen wurden.
Romexis-Client.md
+76
@@ -0,0 +1,76 @@
[Deutsch](Romexis-Client.de) | **English**
# Romexis Client
The `romexis-client` service provides browser-based access to the Linux Romexis Client through the same X11/noVNC runtime concept used by the Admin container.
It is built independently from `romexis-admin`: both images share `romexis-gui-runtime`, while the Client application files come from the dedicated `romexis-client-payload` image.
---
## Image Dependencies
```text
romexis-client-payload:<version>
|
v
romexis-gui-runtime:1-<arch>
|
v
romexis-client:<version>-<arch>
```
The separation prevents Admin-only changes from forcing a Client rebuild and keeps the large installer extraction independent from architecture-specific GUI dependencies.
---
## Runtime Components
The shared GUI runtime provides:
```text
Java 17
OpenJFX
Xvfb
Openbox
x11vnc
noVNC / websockify
GTK / Mesa / OpenGL dependencies
Chilkat
DxService compatibility library
```
The final Client image adds the version-specific Romexis Client payload and the Client startup/test scripts.
---
## Access
The Client is exposed through noVNC. The concrete host port is controlled by the Compose configuration.
For logs:
```bash
docker compose logs -f romexis-client
```
Open a shell for troubleshooting:
```bash
docker compose run --rm --entrypoint /bin/bash romexis-client
```
---
## Build and Tags
Published version tags follow the same pattern as Server and Admin:
```text
romexis-client:<version>-amd64
romexis-client:<version>-arm64
romexis-client:<version>
romexis-client:latest
```
The architecture tags are created first. The public multi-architecture tags are published only after both architectures completed successfully.
Runtime-Layout.de.md
+20 -1
@@ -39,6 +39,9 @@ firebird
romexis-admin
Browser-accessible Romexis Admin / RomexisConfig runtime.
romexis-client
Browser-accessible Romexis Client runtime.
romexis-app
Tomcat-based mRomexis Web App.
@@ -46,7 +49,10 @@ proxy
OpenResty/Nginx proxy for mRomexis Web App.
romexis-migration
Optional migration service for MSSQL workflows.
Migration service for upload, validation and restore workflows.
romexis-control-agent
Restricted container-control service used for coordinated runtime operations.
```
---
@@ -78,6 +84,19 @@ romexis-migration
Der Admin-Container bietet Browserzugriff über noVNC und verwendet VNC-Statusdateien, um RomexisConfig abhängig von aktiven Sitzungen zu starten oder zu stoppen.
## Client-Container-Pfade
```text
/opt/romexis/client
/opt/romexis/sconfig
/programdata/Planmeca/Romexis
/tmp/romexis-client-vnc-state
```
Der Client-Container verwendet dieselbe gemeinsame GUI-Runtime wie Admin, erhält seine Anwendungsdateien jedoch aus dem separaten Image `romexis-client-payload`.
---
---
## Pfade der mRomexis Web App
Runtime-Layout.md
+20 -1
@@ -39,6 +39,9 @@ firebird
romexis-admin
Browser-accessible Romexis Admin / RomexisConfig runtime.
romexis-client
Browser-accessible Romexis Client runtime.
romexis-app
Tomcat-based mRomexis Web App.
@@ -46,7 +49,10 @@ proxy
OpenResty/Nginx proxy for mRomexis Web App.
romexis-migration
Optional migration service for MSSQL workflows.
Migration service for upload, validation and restore workflows.
romexis-control-agent
Restricted container-control service used for coordinated runtime operations.
```
---
@@ -78,6 +84,19 @@ romexis-migration
The Admin container provides browser access through noVNC and uses VNC state files to start or stop RomexisConfig based on active sessions.
## Client Container Paths
```text
/opt/romexis/client
/opt/romexis/sconfig
/programdata/Planmeca/Romexis
/tmp/romexis-client-vnc-state
```
The Client container uses the same shared GUI runtime as Admin, but receives its application files from the separate `romexis-client-payload` image.
---
---
## mRomexis Web App Paths
Server-Image.de.md
+19 -12
@@ -21,7 +21,6 @@ ROMEXIS_FIREBIRD_PAYLOAD_IMAGE
ROMEXIS_VERSION
TARGETARCH
IMAGE_SUFFIX
CHILKAT_VERSION
```
Beispielvorgaben:
@@ -31,9 +30,9 @@ ARG TARGETARCH=amd64
ARG ROMEXIS_VERSION=6.5.3.444.203
ARG IMAGE_SUFFIX=
ARG ROMEXIS_BASE_IMAGE=gitea.buchhorster.de/planmeca/romexis-base-jre:11-${TARGETARCH}${IMAGE_SUFFIX}
ARG ROMEXIS_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-payload:${ROMEXIS_VERSION}${IMAGE_SUFFIX}
ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest${IMAGE_SUFFIX}
ARG ROMEXIS_BASE_IMAGE=gitea.buchhorster.de/planmeca/romexis-base-jre:11
ARG ROMEXIS_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-payload:${ROMEXIS_VERSION}
ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest
```
---
@@ -41,19 +40,27 @@ ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebir
## Build-Stufen
```text
Stage 1: romexis-payload
Imports /opt/romexis and /opt/romexis-mssql-db.
Build context: romexis-server-runtime
Provides Java 11, Chilkat and RomexisPropertyAgent.jar.
Stage 2: romexis-firebird-payload
Imports /opt/romexis-firebird-db.
Build context: romexis-payload
Provides /opt/romexis and /opt/romexis-mssql-db.
Stage 3: agent-build
Compiles RomexisPropertyAgent.java.
Build context: romexis-firebird-payload
Provides /opt/romexis-firebird-db.
Stage 4: final image
Assembles runtime image.
Final stage
Uses romexis-server-runtime as its filesystem base and assembles payloads plus runtime scripts.
```
## BuildKit-Abhängigkeitskontexte
Die lokalen und CI-Build-Skripte übergeben Runtime- und Payload-Images als explizite BuildKit-Named-Image-Contexts. Dadurch ist die Abhängigkeitskette eindeutig; CI kann commit-spezifische Staging-Images verwenden, während lokale Builds isolierte lokale Aliase nutzen können.
Das finale Server-Dockerfile kompiliert Chilkat oder den PropertyAgent nicht mehr selbst; diese Artefakte werden aus der gemeinsamen Server-Runtime materialisiert.
---
---
## Laufzeitskripte
Server-Image.md
+19 -12
@@ -21,7 +21,6 @@ ROMEXIS_FIREBIRD_PAYLOAD_IMAGE
ROMEXIS_VERSION
TARGETARCH
IMAGE_SUFFIX
CHILKAT_VERSION
```
Example defaults:
@@ -31,9 +30,9 @@ ARG TARGETARCH=amd64
ARG ROMEXIS_VERSION=6.5.3.444.203
ARG IMAGE_SUFFIX=
ARG ROMEXIS_BASE_IMAGE=gitea.buchhorster.de/planmeca/romexis-base-jre:11-${TARGETARCH}${IMAGE_SUFFIX}
ARG ROMEXIS_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-payload:${ROMEXIS_VERSION}${IMAGE_SUFFIX}
ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest${IMAGE_SUFFIX}
ARG ROMEXIS_BASE_IMAGE=gitea.buchhorster.de/planmeca/romexis-base-jre:11
ARG ROMEXIS_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-payload:${ROMEXIS_VERSION}
ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest
```
---
@@ -41,19 +40,27 @@ ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebir
## Build Stages
```text
Stage 1: romexis-payload
Imports /opt/romexis and /opt/romexis-mssql-db.
Build context: romexis-server-runtime
Provides Java 11, Chilkat and RomexisPropertyAgent.jar.
Stage 2: romexis-firebird-payload
Imports /opt/romexis-firebird-db.
Build context: romexis-payload
Provides /opt/romexis and /opt/romexis-mssql-db.
Stage 3: agent-build
Compiles RomexisPropertyAgent.java.
Build context: romexis-firebird-payload
Provides /opt/romexis-firebird-db.
Stage 4: final image
Assembles runtime image.
Final stage
Uses romexis-server-runtime as its filesystem base and assembles payloads plus runtime scripts.
```
## BuildKit Dependency Contexts
The local and CI build scripts pass runtime and payload images as explicit BuildKit named image contexts. This makes the dependency chain unambiguous and allows CI to use commit-specific staging images while local builds can use isolated local aliases.
The final Server Dockerfile no longer compiles Chilkat or the PropertyAgent itself; those artifacts are materialized from the shared server runtime.
---
---
## Runtime Scripts
_Sidebar.md
+2
@@ -20,6 +20,7 @@
### Runtime Services
- [Romexis Admin](Romexis-Admin)
- [Romexis Client](Romexis-Client)
- [mRomexis Web App](mRomexis-WebApp)
- [Runtime Layout](Runtime-Layout)
- [Backup and Restore](Backup-and-Restore)
@@ -77,6 +78,7 @@
### Runtime-Dienste
- [Romexis Admin](Romexis-Admin.de)
- [Romexis Client](Romexis-Client.de)
- [mRomexis Web App](mRomexis-WebApp.de)
- [Runtime-Layout](Runtime-Layout.de)
- [Sicherung und Wiederherstellung](Backup-and-Restore.de)