qt6-migration-pipeline/prompts/make-rpm-option.prompt.md

Passe das Script

./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

so an, dass es das Script

./jenkins-ci-rme/jenkins_builder_ubuntu26.sh

innerhalb des von new_docker_build.sh gebauten bzw. verwendeten Docker-Images ausführt.

Kontext:

• Script A: ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

• Script B: ./jenkins-ci-rme/jenkins_builder_ubuntu26.sh

• Script C: ./rpmbuild/make_rpm_ubuntu26.py

• Script B ruft Script C auf, um RPM- und DEB-Pakete zu erzeugen.

• Das Docker-Image, das von Script A gebaut oder verwendet wird, soll alle notwendigen Tools enthalten, damit Script B und Script C erfolgreich laufen.

• Die erzeugten RPM-/DEB-Pakete sollen nach dem Docker-Lauf auf dem ausführenden Host verfügbar sein, z. B. über einen bind mount / Ausgabe-Mountpunkt.

Gewünschte Änderungen:

1. Neue Option in Script A hinzufügen

   • Füge eine neue CLI-Option hinzu, z. B.:

     --run-jenkins-builder

   • Wenn diese Option gesetzt ist, soll Script A nach dem Docker-Image-Build bzw. beim Docker-Run das Script B innerhalb des Docker-Containers ausführen.

2. Ausgabe-Mountpunkt hinzufügen

   • Füge eine Option hinzu, z. B.:

     --package-output-dir

   • Dieser Pfad liegt auf dem Host.

   • Der Pfad soll beim Docker-Run in den Container gemountet werden.

   • Die von Script B/C erzeugten RPM-/DEB-Pakete sollen anschließend dort verfügbar sein.

   • Falls kein Pfad angegeben wird, verwende einen sinnvollen Default, z. B.:

     ./packages-out

3. Docker-Image erweitern

   • Stelle sicher, dass im Docker-Image alle Tools installiert sind, die für Script B und C benötigt werden.
   • Analysiere dazu:
     • ./jenkins-ci-rme/jenkins_builder_ubuntu26.sh
     • ./rpmbuild/make_rpm_ubuntu26.py
     • ggf. vorhandene Dockerfiles oder Paketlisten
   • Installiere fehlende Tools im Image, z. B. je nach Bedarf:
     • python3
     • python3-pip
     • rpm/rpmbuild
     • debhelper
     • dpkg-dev
     • fakeroot
     • build-essential
     • git
     • cmake
     • ninja-build
     • qt6-related packages
     • sonstige tatsächlich benötigte Abhängigkeiten

4. Docker-Ausführung

   • Wenn --run-jenkins-builder gesetzt ist, soll Script A den Container so starten, dass:
     • das Repository bzw. der relevante Workspace im Container verfügbar ist
     • Script B im Container ausgeführt wird
     • der Paket-Ausgabeordner vom Host in den Container gemountet wird
     • am Ende die erzeugten .rpm und .deb Dateien auf dem Host sichtbar sind Zusätzliche Anforderungen zu Umgebungsvariablen:

Script A benötigt für den neuen Ablauf folgende Variablen:

PROJECT LTS flavor: qatar | ahtc | guez (cmake -D_pname) OS_VERSION Ubuntu version, e.g. 26.04 LTS_VERSION Major.minor LTS version, e.g. 1.0 GUEZ_MODE ON | OFF — cmake -DGUEZ_MODE WORKSPACE Jenkins workspace path, normally set automatically by Jenkins PROJECT_BASE_DIR Path used by make_rpm_ubuntu26.py as the source tree BUILD_NUMBER Jenkins build number, used as release in DEB version BUILD_TAG Jenkins build tag

Für den Docker-Aufruf aus Script A sollen mindestens diese Werte gesetzt bzw. in den Container übergeben werden:

PROJECT=guez GUEZ_MODE=ON PROJECT_BASE_DIR="${MIGRATE_PIPELINE_ROOT}/qt-migration-legatus/qt6-after/qt6-migrated-legatus"

Die übrigen benötigten Variablen sollen robust bestimmt oder sinnvoll gesampelt werden, falls sie außerhalb von Jenkins nicht gesetzt sind:

OS_VERSION: - wenn möglich aus dem Docker-Image bzw. Container bestimmen, z. B. über /etc/os-release - erwarteter Wert für Ubuntu 26.04: 26.04

LTS_VERSION: - falls nicht gesetzt, sinnvollen Default verwenden, z. B. 1.0 - optional als CLI-Option überschreibbar machen

WORKSPACE: - falls nicht gesetzt, auf den Repository-/Arbeitsverzeichnis-Pfad im Container setzen

BUILD_NUMBER: - falls nicht gesetzt, auf einen lokalen Default setzen, z. B. 0 oder 1 - wichtig: Wert muss für make_rpm_ubuntu26.py verwendbar sein

BUILD_TAG: - falls nicht gesetzt, aus PROJECT, BUILD_NUMBER und lokalem Kontext erzeugen, z. B. local-${PROJECT}-${BUILD_NUMBER}

Die Variablen sollen beim Docker-Run explizit mit -e in den Container übergeben werden, damit jenkins_builder_ubuntu26.sh und make_rpm_ubuntu26.py dieselbe Umgebung sehen wie in Jenkins.

Beispielhafte Übergabe:

-e PROJECT=guez -e GUEZ_MODE=ON -e OS_VERSION="${OS_VERSION}" -e LTS_VERSION="${LTS_VERSION}" -e WORKSPACE="${CONTAINER_WORKSPACE}" -e PROJECT_BASE_DIR="${PROJECT_BASE_DIR}" -e BUILD_NUMBER="${BUILD_NUMBER}" -e BUILD_TAG="${BUILD_TAG}"

Akzeptanzkriterium zusätzlich:

• Beim neuen Ablauf mit --run-jenkins-builder sind alle oben genannten Variablen im Container gesetzt.
• PROJECT, GUEZ_MODE und PROJECT_BASE_DIR haben die vorgegebenen Werte.
• Die restlichen Werte werden entweder aus der vorhandenen Umgebung übernommen, aus dem Docker-Image/Container bestimmt oder mit nachvollziehbaren lokalen Defaults gesetzt.

5. Robustheit

   • Prüfe, ob Script B existiert und ausführbar ist.
   • Falls nötig, setze executable permissions oder rufe es explizit mit bash auf.
   • Prüfe, ob der Ausgabeordner existiert; falls nicht, erstelle ihn.
   • Verwende absolute Pfade für Docker volume mounts.
   • Brich bei Fehlern mit aussagekräftigen Fehlermeldungen ab.
   • Verwende set -euo pipefail, sofern passend und noch nicht vorhanden.
   • Bestehendes Verhalten von Script A darf ohne die neue Option nicht verändert werden.

6. Dokumentation

   • Aktualisiere ggf. vorhandene README- oder Hilfetexte.
   • Die Usage-Ausgabe von Script A soll die neuen Optionen beschreiben.

7. Tests / Validierung

   • Führe soweit möglich ShellCheck oder eine vergleichbare Prüfung für geänderte Shell-Scripts aus.

   • Prüfe mindestens syntaktisch:

     • Script A
     • Script B

   • Wenn möglich, teste den neuen Ablauf mit:

     ./qt-migration-legatus/qt6-after/qt6-migrated-legatusnew_docker_build.sh --run-jenkins-builder --package-output-dir ./packages-out

Akzeptanzkriterien:

• Script A hat eine neue Option zum Ausführen von Script B im Docker-Container.
• Script B läuft innerhalb des Docker-Images D, das durch Script A gebaut/verwendet wird.
• Script C wird über Script B ausgeführt.
• Das Docker-Image enthält alle notwendigen Build- und Packaging-Tools.
• Die erzeugten RPM-/DEB-Pakete sind nach Ende des Laufs auf dem Host unter dem angegebenen Ausgabeordner verfügbar.
• Ohne neue Option bleibt das bisherige Verhalten von Script A unverändert.
• Änderungen sind nachvollziehbar, robust und dokumentiert.