Verbesserung des Hogajama Build-Prozesses.
Rahmenbedingung: Soll in kleinen Schritten möglich sein. Teile können in Sub-Issues implementiert werden.
Abgrenzung: Nur Hogajama, nicht andere Komponenten wie Kafka oder Couchbase.
Status
Derzeit haben wir folgende Build-Configs:
- s2i-builder-maven: Baut das s2i Builder Image von https://github.com/Gepardec/openshift-builder-maven
- hogajama-binary: Kompiliert Hogajama mit dem s2i Builder Image. Generiert Deployment Artefakte in einem Build-Image
- hogajama-run: Erzeugt eine WildFly Instanz mit einem WildFly Base Image und dem Build-Image
Das erzeugte WildFy Image wird von einem EAP-Operator verwendet.
Probleme
Der aktuelle Prozess hat folgende Probleme:
- Die Build-Schritte müssen manuell getriggert werden.
- Die Maven Artefakte werden immer neu von Maven-Central geladen. Das Gepardec openshift-builder-maven Image unterstützt keine inkrementellen Builds.
- Der EAP-Operator bietet keinen erkennbaren Mehrwert.
- CLI-Skripts für die lokale EAP-Konfiguration können nicht einfach wiederverwendet werden.
- Werden weitere Services installiert wie z.B. Mock-GUI, dann werden die Sourcen neu kompiliert. Das widerspricht dem "Build-Once" Grundsatz von Build-Pipelines
- Ändert sich die Kafka-Installation, muss das Zertifikat im Git-Repo eingecheckt und neu gebaut werden.
Verbesserung des Hogajama Build-Prozesses.
Rahmenbedingung: Soll in kleinen Schritten möglich sein. Teile können in Sub-Issues implementiert werden.
Abgrenzung: Nur Hogajama, nicht andere Komponenten wie Kafka oder Couchbase.
Status
Derzeit haben wir folgende Build-Configs:
Das erzeugte WildFy Image wird von einem EAP-Operator verwendet.
Probleme
Der aktuelle Prozess hat folgende Probleme: