Table of Contents
- CI/CD-Pipeline
- Hauptaufgaben der Pipeline
- Pipeline-Graph und Parallelität
- Behandlung von Branch-Suffixen
- Änderungserkennung und Versionsmatrix
- Payload-Buildlogik
- Firebird-Payload-Build
- Gemeinsame Runtime-Builds und Registry-Cache
- Server-Build
- Admin-Build
- Client-Build
- mRomexis-Web-App-Build
- Push gegenüber Load
- Häufige CI-Fehlersuche
Deutsch | English
CI/CD-Pipeline
Das Projekt verwendet Drone CI, um Images zu bauen und in der Gitea-Container-Registry zu veröffentlichen.
Hauptaufgaben der Pipeline
Die Pipeline baut:
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:
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
Für main werden Image-Tags ohne Suffix veröffentlicht.
Bei Feature-Branches wird der Branchname normalisiert und als Image-Suffix angehängt:
-feature-romexis-admin
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 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:
| Änderung | Verhalten |
|---|---|
| Neue Version hinzugefügt | nur neue Version bauen |
| Vorhandene URL geändert | betroffene Version erzwungen neu bauen |
| Kopierzuordnung geändert | alle Payload-Versionen neu bauen |
| Extraktionsskript geändert | alle Payload-Versionen neu bauen |
Firebird-Payload-Build
Das Firebird-Payload wird nach dem Windows-Romexis-Payload-Schritt gebaut.
Es verwendet:
romexis-firebird-payload/romexis-firebird-versions.env
Der Build veröffentlicht:
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 kombiniert die ausgewählte Server-Runtime, das Romexis-Payload und das Firebird-Payload über explizite BuildKit-Image-Contexts:
romexis-server-runtime
romexis-payload
romexis-firebird-payload
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 die gemeinsame GUI-Runtime zusammen mit dem Romexis-Server-/Admin-Payload und baut:
romexis-admin:<version>-amd64
romexis-admin:<version>-arm64
romexis-admin:<version>
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
mRomexis-Web-App-Images werden nur für Romexis-Versionen gebaut, für die gilt:
version >= 6.5.3
Ältere Versionen werden übersprungen, weil das Payload Folgendes nicht enthält:
/opt/romexis/broker/mromexis-html.war
Veröffentlichte Tags:
romexis-mromexis-app:<version>-amd64
romexis-mromexis-app:<version>-arm64
romexis-mromexis-app:<version>
romexis-mromexis-app:latest
Push gegenüber Load
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.
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.
Häufige CI-Fehlersuche
Build ist nach dem Leeren des Caches zu schnell
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
Wenn das Server-Dockerfile auf Folgendes verweist:
romexis-firebird-payload:latest
muss die Firebird-Payload-Pipeline latest veröffentlichen.
mRomexis-Build übersprungen
Die Romexis-Version prüfen. Die mRomexis Web App wird nur für 6.5.3 und neuer gebaut.
Payload fehlt im endgültigen Image
Das endgültige Image prüfen:
docker run --rm --entrypoint find gitea.buchhorster.de/planmeca/romexis-server:<tag> /opt -maxdepth 3 -type f
Romexis Docker Wiki
English
Getting Started
- Project Overview
- Architecture
- Quick Start
- Synology Quick Start
- Use with Docker + WSL in Windows
- Compose Runtime
- Configuration
- Container Images
Runtime Services
- Romexis Admin
- Romexis Client
- mRomexis Web App
- Runtime Layout
- Backup and Restore
- Troubleshooting
- Security
Build System
Database
Migration
Development
Source Documents
Deutsch
Erste Schritte
- Projektübersicht
- Architektur
- Schnellstart
- Synology Quick Start
- Nutzung mit Docker + WSL unter Windows
- Compose-Runtime
- Konfiguration
- Container-Images
Runtime-Dienste
- Romexis Admin
- Romexis Client
- mRomexis Web App
- Runtime-Layout
- Sicherung und Wiederherstellung
- Fehlerbehebung
- Sicherheit
Build-System
Datenbank
Migration
Entwicklung
Quelldokumente
Romexis Docker Project Wiki / Romexis-Docker-Projekt-Wiki
English Home · Deutsche Startseite · English source documents · Deutsche Quelldokumente · Security · Sicherheit
Internal operations and development wiki / Internes Betriebs- und Entwicklungswiki