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

Deutsch | English

Payload-Images

Payload-Images sind wiederverwendbare Zwischenimages, die extrahierte Installerinhalte enthalten.


Windows-Payload

Verzeichnis:

romexis-payload/

Zweck:

  • offiziellen Windows-Installer herunterladen
  • erforderliche InstallShield-CAB-Komponenten extrahieren
  • /opt/romexis erstellen
  • MSSQL-Initialisierungs-SQL-Dateien extrahieren
  • /opt/romexis/version schreiben

Ausgabevertrag:

/opt/romexis
/opt/romexis-mssql-db
/opt/romexis/version
/opt/romexis/server/RomexisServer.jar

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:

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

Unterstützte URLs für Windows-Installer werden hier gepflegt:

romexis-payload/romexis-versions.env

Beispiel:

6_5_3_444_203=https://content.planmeca.com/files/Planmeca_Romexis_6.5.3.444.203_Win.zip

Kopierzuordnung

Die Installerextraktion wird gesteuert durch:

romexis-payload/romexis-copy-map.tsv

Format:

Source<TAB>Destination

Beispiel:

Server_jar	/opt/romexis/server
Server_Program_64bit/server/*.xml	/opt/romexis/server

Wenn sich diese Zuordnung ändert, sollten alle Payload-Versionen neu gebaut werden, weil sich das extrahierte Laufzeitlayout geändert haben kann.


Firebird-Payload

Verzeichnis:

romexis-firebird-payload/

Zweck:

  • offizielles macOS-DMG herunterladen
  • PKG-Payloads extrahieren
  • Firebird-Datenbank-SQL-Skripte sammeln
  • ursprüngliche Hilfsskripte für Backup und Wiederherstellung sammeln
  • romexis_new.fdb als Referenz/Vorlage aufnehmen

Ausgabevertrag:

/opt/romexis-firebird-db/version
/opt/romexis-firebird-db/scripts
/opt/romexis-firebird-db/tools
/opt/romexis-firebird-db/templates
/opt/romexis-firebird-db/layout

Wichtige Dateien:

/opt/romexis-firebird-db/scripts/rxdb.sh
/opt/romexis-firebird-db/scripts/rxupd.sh
/opt/romexis-firebird-db/scripts/RX_Base_10fb_MAC.sql
/opt/romexis-firebird-db/scripts/RX_Update_653.sql
/opt/romexis-firebird-db/tools/Romexis_Firebird_Backup.sh
/opt/romexis-firebird-db/tools/Romexis_Firebird_Restore.sh
/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:

romexis-payload:ci-<commit>-<version>
romexis-client-payload:ci-<commit>-<version>

Dadurch ersetzen experimentelle Extraktionsänderungen keine stabilen versionierten Payloads.



Ein Payload-Image untersuchen

Wenn ein Payload-Image auf scratch basiert, besitzt es möglicherweise keine Shell.

Verwendung:

docker save gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest -o payload.tar
mkdir payload rootfs
tar -xf payload.tar -C payload
tar -xf payload/<layer-id>/layer.tar -C rootfs
find rootfs/opt -type f | sort

Wenn das Image eine Shell enthält:

docker run --rm -it --entrypoint sh   gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest