Adds first release providing prompt
This commit is contained in:
1 file changed
+290
@@ -0,0 +1,290 @@
|
||||
# Copilot CLI Prompt: Erstes Release ausgewählter Qt6-Migrationsmodule
|
||||
|
||||
Dieser Prompt ist verbindlicher Task-Kontext. Arbeite autonom, minimal, reproduzierbar und ohne opportunistische Änderungen.
|
||||
|
||||
## Required base prompt
|
||||
|
||||
Vor jeder Änderung lesen und anwenden:
|
||||
|
||||
- `./prompts/commit-policy.prompt.md`
|
||||
|
||||
Wenn der Commit-/Repository-Prompt strenger ist, gilt er zusätzlich. Dieser Prompt konkretisiert nur das Release-Ziel und den Release-Scope.
|
||||
|
||||
## Ziel
|
||||
|
||||
Erstelle das erste Release von ausgewählten Modulen aus dem bereits weit fortgeschritten nach Qt6 migrierten Projekt.
|
||||
|
||||
Das Release ist kein erneuter Qt5-zu-Qt6-Migrationslauf. Migriere, repariere oder ergänze Code nur, wenn es direkt erforderlich ist, damit die explizit freigegebenen Module im Release sauber konfigurieren, bauen, testen und als RPM über die Pipeline erzeugt werden.
|
||||
|
||||
## Zielbranch
|
||||
|
||||
Arbeite auf dem bestehenden Zielbranch:
|
||||
|
||||
- `story/release-at-16-oct-2026`
|
||||
|
||||
Wenn der aktuelle Branch bereits korrekt ist, bleibe dort. Wenn nicht, wechsle minimal auf diesen Branch. Erstelle keine neuen Branches, außer es ist technisch unumgänglich und klar begründet.
|
||||
|
||||
## Repository- und Submodule-Kontext
|
||||
|
||||
Die Workspace-Struktur enthält mehrere Repositories/Submodule. Bestimme für jede Datei anhand ihres Pfads das zuständige Repository und committe Änderungen nur dort.
|
||||
|
||||
Erwartete Submodule:
|
||||
|
||||
```text
|
||||
./gitmodules
|
||||
[submodule "qt-migration-legatus"]
|
||||
path = qt-migration-legatus
|
||||
url = git@devel:lifemaps/qt-migration-legatus.git
|
||||
branch = story/release-at-16-oct-2026
|
||||
[submodule "rpmbuild"]
|
||||
path = rpmbuild
|
||||
url = git@devel:lifemaps/rpmbuild.git
|
||||
branch = story/release-at-16-oct-2026
|
||||
[submodule "jenkins-ci-rme"]
|
||||
path = jenkins-ci-rme
|
||||
url = git@devel:lifemaps/rme-jenkins.git
|
||||
branch = story/release-at-16-oct-2026
|
||||
|
||||
./qt-migration-legatus/.gitmodules
|
||||
[submodule "qt5-before/qt5-legatus-legacy"]
|
||||
path = qt5-before/qt5-legatus-legacy
|
||||
url = git@devel:lifemaps/qt5-legatus-legacy.git
|
||||
branch = story/qt6-migration
|
||||
```
|
||||
|
||||
Alle Release-relevanten Repositories/Submodule müssen auf `story/release-at-16-oct-2026` stehen, außer das Qt5-Legacy-Submodule ist nur als Vergleichsquelle erforderlich und laut `.gitmodules` auf `story/qt6-migration` gebunden.
|
||||
|
||||
## Harte Release-Grenze
|
||||
|
||||
Im Release dürfen ausschließlich die unten explizit angegebenen Teile enthalten sein.
|
||||
|
||||
Nicht erlaubt:
|
||||
|
||||
- zusätzliche Module, Verzeichnisse, Targets oder Tests außerhalb des Release-Scopes
|
||||
- opportunistische Refactorings, Cleanups oder Modernisierungen
|
||||
- entfernte oder nicht freigegebene Module wieder einzuführen
|
||||
- Build- oder Testfehler durch Deaktivieren relevanter Targets zu verstecken
|
||||
- Tests zu löschen, zu schwächen oder aus CTest zu entfernen, nur damit das Release grün wird
|
||||
- generierte Artefakte einzuchecken
|
||||
- Stub-, Dummy-, Mock- oder Placeholder-Dateien als Ersatz für echte Build-/Generator-Ausgaben zu erzeugen
|
||||
|
||||
Wenn ein nicht gelisteter Teil technisch erforderlich ist, damit die gelisteten Module bauen oder testen, darf nur die kleinste notwendige Datei/Komponente aufgenommen werden. Begründe jede solche Ausnahme einzeln im finalen Bericht.
|
||||
|
||||
## Release-Inhalt aus `qt-migration-legatus`
|
||||
|
||||
Aus:
|
||||
|
||||
- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus`
|
||||
|
||||
dürfen im Release nur diese Teile enthalten sein:
|
||||
|
||||
- `./TetraIF`
|
||||
- `./Z`
|
||||
- `./CMakeLists.txt`
|
||||
- `./cmake`
|
||||
- `./tests`
|
||||
- `./new_docker_build.sh`
|
||||
- `./specs`
|
||||
- `./Lts/Application`
|
||||
- `./forward-declarations/` nur soweit für Build und Tests zwingend erforderlich
|
||||
- `./.forward-declarations/` nur soweit für Build und Tests zwingend erforderlich
|
||||
|
||||
Entferne alle nicht benötigten Dateien aus dem Release-Branch. Dateien außerhalb der oben ausdrücklich erlaubten Pfade dürfen nicht im Release-Pfad verbleiben, außer sie sind technisch zwingend für Build, Tests oder Paketierung der freigegebenen Module erforderlich. Nimm in diesem Fall nur die kleinste erforderliche Datei bzw. Komponente auf und begründe die Ausnahme einzeln im finalen Bericht.
|
||||
|
||||
Prüfe und dokumentiere, welche Dateien aus `./forward-declarations/` tatsächlich benötigt werden. Nicht benötigte Forward Declarations dürfen nicht im Release verbleiben.
|
||||
|
||||
## Release-Inhalt aus `qt6-migration-pipeline`
|
||||
|
||||
Aus:
|
||||
|
||||
- `./qt6-migration-pipeline`
|
||||
|
||||
dürfen im Release nur diese Teile enthalten sein:
|
||||
|
||||
- `./jenkins-ci-rme`
|
||||
- `./rpmbuild/make_rpm_ubuntu26.py`
|
||||
|
||||
Entferne alle nicht benötigten Dateien aus dem Release-Branch. Dateien außerhalb der oben ausdrücklich erlaubten Pfade dürfen nicht im Release-Pfad verbleiben, außer sie sind technisch zwingend für Build, Tests oder Paketierung der freigegebenen Module erforderlich. Nimm in diesem Fall nur die kleinste erforderliche Datei bzw. Komponente auf und begründe die Ausnahme einzeln im finalen Bericht.
|
||||
|
||||
Die Jenkins-Pipeline muss die freigegebenen Module bauen, testen und RPMs erzeugen. Passe nur die hierfür erforderlichen Pipeline-/RPM-Dateien an.
|
||||
|
||||
## Build- und Testautorität
|
||||
|
||||
Die freigegebenen Module müssen über dieses Skript bauen:
|
||||
|
||||
- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh`
|
||||
|
||||
Passe `./new_docker_build.sh` für das Release an.
|
||||
|
||||
Das Skript muss:
|
||||
|
||||
- nur die freigegebenen Release-Module konfigurieren und bauen
|
||||
- alle für diese Release-Module relevanten CMake-Targets bauen oder validieren
|
||||
- CTest für die Release-relevanten Tests aus `./tests` ausführen
|
||||
- bei Build-, Link- oder Testfehlern fehlschlagen
|
||||
- keine nicht freigegebenen Module als versteckte Abhängigkeit bauen
|
||||
- keine host-lokalen Pfade oder Entwicklerannahmen verwenden
|
||||
- im Docker-/CI-Kontext reproduzierbar laufen
|
||||
|
||||
## CTest-Umfang
|
||||
|
||||
Alle Tests aus:
|
||||
|
||||
- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests`
|
||||
|
||||
die die herausgegebenen Module betreffen, müssen im Release enthalten sein, bauen und erfolgreich durchlaufen.
|
||||
|
||||
Vorgehen:
|
||||
|
||||
1. Identifiziere alle CTest-Tests, die `TetraIF`, `Z`, `Lts/Application`, `specs`, zentrale `cmake`-Logik oder erforderliche Forward Declarations betreffen.
|
||||
2. Stelle sicher, dass diese Tests registriert sind.
|
||||
3. Stelle sicher, dass sie durch `./new_docker_build.sh` gebaut und ausgeführt werden.
|
||||
4. Entferne oder ignoriere keine relevanten Tests, nur um Fehler zu verdecken.
|
||||
5. Tests für nicht freigegebene Module dürfen nicht Bestandteil des Release-Pfads sein, außer sie sind direkte Integrationsvoraussetzung für die freigegebenen Module und werden begründet.
|
||||
|
||||
## Jenkins-/RPM-Anforderungen
|
||||
|
||||
Die Jenkins-Pipeline in `./jenkins-ci-rme` muss für das Release:
|
||||
|
||||
- den Release-Scope auschecken oder verwenden
|
||||
- `./new_docker_build.sh` für Build und Tests ausführen
|
||||
- CTest-Fehler als Pipeline-Fehler behandeln
|
||||
- RPM-Erzeugung über `./rpmbuild/make_rpm_ubuntu26.py` auslösen
|
||||
- nur die freigegebenen Module paketieren
|
||||
- keine nicht freigegebenen Module, Artefakte oder Tests in RPMs aufnehmen
|
||||
- reproduzierbare Ubuntu-26-RPMs erzeugen
|
||||
|
||||
Passe `./rpmbuild/make_rpm_ubuntu26.py` nur soweit an, wie es für das Release-Paketieren der erlaubten Teile erforderlich ist.
|
||||
|
||||
## Scope-Prüfungen vor Änderungen
|
||||
|
||||
Vor jeder Änderung:
|
||||
|
||||
1. Ermittle alle Git-Repositories und Submodule.
|
||||
2. Prüfe Branch, Remote, Working Tree und Submodule-Status.
|
||||
3. Liste jede geplante Dateiänderung auf.
|
||||
4. Ordne jede geplante Datei exakt einem Repository zu.
|
||||
5. Stoppe, wenn Repository-Zuordnung, Branch oder Remote nicht eindeutig sind.
|
||||
|
||||
## Release-Scope-Audit
|
||||
|
||||
Führe vor Implementierung und vor Abschluss ein Scope-Audit durch:
|
||||
|
||||
- Liste alle Verzeichnisse/Dateien, die im Release enthalten wären.
|
||||
- Vergleiche diese Liste gegen den erlaubten Release-Scope.
|
||||
- Entferne oder schließe nicht erlaubte Teile aus.
|
||||
- Prüfe CMake-Targets und Install-/Package-Regeln auf nicht erlaubte Module.
|
||||
- Prüfe Tests auf nicht erlaubte Module.
|
||||
- Prüfe Jenkins und RPM-Spezifikation/-Script auf nicht erlaubte Artefakte.
|
||||
|
||||
Wenn ein nicht erlaubter Teil referenziert wird, behebe die Referenz oder erkläre, warum er direkt und zwingend für die erlaubten Module erforderlich ist.
|
||||
|
||||
## CMake-/Target-Regeln
|
||||
|
||||
Für die erlaubten Module:
|
||||
|
||||
- entdecke reale CMake-Targets unter `TetraIF`, `Z` und `Lts/Application`
|
||||
- erfinde keine Targets
|
||||
- füge keine Targets hinzu, die nicht existieren
|
||||
- registriere nur erforderliche Targets im Release-Build
|
||||
- stelle sicher, dass Parent-`CMakeLists.txt` nur freigegebene Module aktiviert
|
||||
- stelle sicher, dass install/package-Regeln nur freigegebene Artefakte aufnehmen
|
||||
- prüfe zentrale `cmake`-Hilfen nur soweit, wie sie für die Release-Module erforderlich sind
|
||||
|
||||
## Qt-/Generator-/Forward-Declaration-Regeln
|
||||
|
||||
Falls die Release-Module Qt-, RTI-, ndsgen-, KTextTemplate- oder andere Generator-Flows verwenden:
|
||||
|
||||
- bewahre echte Generator-Flows
|
||||
- generiere in den Build-Tree
|
||||
- konsumiere generierte Dateien aus dem Build-Tree
|
||||
- committe keine generierten Dateien
|
||||
- ersetze Generator-Ausgaben nicht durch handgeschriebene Stubs
|
||||
- stelle Build-Reihenfolge und Include-Pfade korrekt her
|
||||
|
||||
Forward Declarations dürfen nur im Release sein, wenn sie direkt für Build oder Tests der freigegebenen Module erforderlich sind. Dokumentiere jede aufgenommene Forward-Declaration-Datei mit Grund.
|
||||
|
||||
Führe die beiden Verzeichnisse `./forward-declarations/` und `./.forward-declarations/` in `./forward-declarations/` zusammen. Verschiebe bzw. integriere benötigte Dateien aus `./.forward-declarations/` nach `./forward-declarations/`, sodass der Release-Pfad final ausschließlich `./forward-declarations/` verwendet. Passe CMake-Include-Pfade und Referenzen entsprechend an. Erzeuge dabei keine generierten Artefakte, Stubs, Dummies oder Fake-Ausgaben.
|
||||
|
||||
## Erlaubte Änderungen außerhalb der Modulverzeichnisse
|
||||
|
||||
Änderungen außerhalb der gelisteten Modulverzeichnisse sind nur erlaubt, wenn sie direkt für das Release erforderlich sind:
|
||||
|
||||
- Root-`CMakeLists.txt`
|
||||
- zentrale Dateien unter `./cmake`
|
||||
- `./new_docker_build.sh`
|
||||
- Release-relevante Tests unter `./tests`
|
||||
- erforderliche Dateien unter `./forward-declarations/`
|
||||
- `./specs`
|
||||
- `./jenkins-ci-rme`
|
||||
- `./rpmbuild/make_rpm_ubuntu26.py`
|
||||
|
||||
Jede Änderung außerhalb der Modulverzeichnisse muss im finalen Bericht begründet werden.
|
||||
|
||||
## Validierung
|
||||
|
||||
Validiere im Docker-/CI-Pfad. Verwende keine Host-Builds als Ersatz für Docker-Validierung.
|
||||
|
||||
Installiere fehlende Systempakete reproduzierbar über `apt` im Dockerimage; sie dürfen nicht host-lokal vorausgesetzt werden.
|
||||
|
||||
Mindestens ausführen, sofern die Pfade existieren:
|
||||
|
||||
```bash
|
||||
cd ./qt-migration-legatus/qt6-after/qt6-migrated-legatus
|
||||
./new_docker_build.sh
|
||||
```
|
||||
|
||||
CTest muss als Teil dieser Validierung laufen. Falls `new_docker_build.sh` CTest noch nicht ausführt, passe es so an, dass die Release-relevanten Tests ausgeführt werden.
|
||||
|
||||
Zusätzlich Jenkins/RPM-Pfad prüfen:
|
||||
|
||||
- Pipeline-Konfiguration in `./jenkins-ci-rme`
|
||||
- RPM-Erzeugung mit `./rpmbuild/make_rpm_ubuntu26.py`
|
||||
|
||||
Wenn eine Validierung wegen Umgebung, Zugang, Lizenz, Docker oder fehlender Infrastruktur nicht möglich ist, klassifiziere den Blocker exakt und berichte, welche Projektvalidierung dennoch durchgeführt wurde.
|
||||
|
||||
## Erfolgskriterien
|
||||
|
||||
Das Release gilt nur als erfolgreich, wenn:
|
||||
|
||||
- der Release-Scope ausschließlich die erlaubten Teile enthält
|
||||
- `TetraIF`, `Z` und `Lts/Application` im Release konfigurieren, bauen und linken
|
||||
- `./new_docker_build.sh` für das Release angepasst ist
|
||||
- alle Release-relevanten Tests aus `./tests` bauen und per CTest erfolgreich laufen
|
||||
- Jenkins die Module baut, testet und RPMs erzeugt
|
||||
- `./rpmbuild/make_rpm_ubuntu26.py` nur die freigegebenen Teile paketiert
|
||||
- keine nicht freigegebenen Module oder Artefakte im Release landen
|
||||
- nur zwingend erforderliche Forward Declarations im Release enthalten sind
|
||||
- keine generierten Artefakte, Stubs, Dummies oder Fake-Erfolge eingecheckt wurden
|
||||
- Änderungen pro Repository korrekt getrennt, validiert und committet wurden
|
||||
|
||||
## Wenn nicht vollständig lösbar
|
||||
|
||||
Fälsche keinen Erfolg. Berichte exakt:
|
||||
|
||||
- welcher Release-Scope umgesetzt wurde
|
||||
- welche erlaubten Module bauen
|
||||
- welche Tests ausgeführt wurden
|
||||
- welche Tests fehlen oder fehlschlagen
|
||||
- welche nicht gelisteten Dateien technisch erforderlich waren
|
||||
- welche Forward Declarations aufgenommen wurden und warum
|
||||
- ob Jenkins Build, Test und RPM-Erzeugung ausführen kann
|
||||
- ob RPM-Erzeugung erfolgreich war
|
||||
- ob der Blocker Umgebung, Projekt, Pfad, Docker, Jenkins, RPM, Lizenz oder Zugang betrifft
|
||||
- welche sicheren Änderungen durchgeführt wurden
|
||||
- welche Risiken verbleiben
|
||||
|
||||
## Finaler Bericht
|
||||
|
||||
Halte den finalen Bericht kurz und faktisch:
|
||||
|
||||
- Status: validiert, teilweise validiert oder blockiert
|
||||
- Branch und Repositories
|
||||
- geänderter Release-Scope
|
||||
- Dateien außerhalb der Modulverzeichnisse und Begründung
|
||||
- `new_docker_build.sh`-Änderungen
|
||||
- ausgeführte Build-/CTest-/Jenkins-/RPM-Kommandos
|
||||
- Ergebnis je Kommando
|
||||
- aufgenommene Forward Declarations
|
||||
- bestätigte Ausschlüsse nicht freigegebener Module
|
||||
- verbleibende Blocker oder Risiken
|
||||
Reference in new issue
Block a user