195 lines
11 KiB
Markdown
195 lines
11 KiB
Markdown
# Copilot CLI Prompt: Erstes Qt6-Release der freigegebenen Module
|
|
|
|
Dieser Prompt ist verbindlicher Task-Kontext. Arbeite autonom, minimal, reproduzierbar und ohne opportunistische Änderungen. Lies vor jeder Änderung `./prompts/commit-policy.prompt.md`; strengere Repository-Regeln gelten zusätzlich.
|
|
|
|
## 1. Ziel und Release-Charakter
|
|
|
|
Erstelle das erste Release der bereits nach Qt6 migrierten Module `TetraIF`, `Z` und `Lts/Common`. Dies ist kein erneuter Qt5→Qt6-Migrationslauf. Code darf nur geändert werden, wenn dies unmittelbar für Build, Tests, Installation oder Packaging des Release-Scope erforderlich ist.
|
|
|
|
Dieses Release ist ausdrücklich ein **Entwickler- und Weiterentwicklungsrelease** der Qt6-Migration, kein reines Runtime- oder Endkundenrelease. Deshalb gehören die Release-relevanten CTests ausdrücklich zum Release: sowohl ihre ausführbaren Binaries als auch ihre C++-Quellen müssen ausgeliefert werden. CTests sind trotz des Begriffs „Release Build“ zu bauen, auszuführen und zu paketieren.
|
|
|
|
Das Release muss als eigene, reproduzierbare DEB-Pakete ausliefern:
|
|
|
|
- Binaries und Bibliotheken der freigegebenen Module;
|
|
- migrierte Qt6-C++-Quellen ausschließlich aus `S`;
|
|
- ausführbare Release-relevante CTest-Programme, Testdaten und deren C++-Quellen;
|
|
- benötigte Dockerfiles, Build-, CMake-, CTest-, Jenkins- und DEB-Packaging-Skripte der reproduzierbaren Build-Pipeline.
|
|
|
|
Nicht zum Release gehörende Workspace-Dateien werden physisch nicht gelöscht. Sie bleiben im Repository/Working Tree erhalten, dürfen aber durch explizite Allowlists und Manifeste nicht in DEBs oder andere Release-Artefakte gelangen.
|
|
|
|
## 2. Begriffe und Scope
|
|
|
|
Ermittle vor jeder Änderung aus realen Projektdateien:
|
|
|
|
- `R`: vollständige Menge aller Module unter `./qt-migration-legatus/qt6-after/qt6-migrated-legatus`;
|
|
- `M = {TetraIF, Z, Lts/Common}`: explizit freigegebene Module;
|
|
- `S`: kleinstes Modulset `M` plus zwingend notwendige direkte/transitive Abhängigkeiten aus `R`;
|
|
- `R \ S`: ausgeschlossene Module.
|
|
|
|
Leite `S` ausschließlich aus realen `CMakeLists.txt`, `add_subdirectory`, Targets, `target_link_libraries`, Includes, Generator-Konfigurationen, Tests, Install- und Packaging-Regeln ab. Dokumentiere jede Abhängigkeit in `S \ M` mit Modul, benötigendem Modul, Grund und konkreter Dateireferenz.
|
|
|
|
### Verbindliche Interpretation der Ausschlussregel
|
|
|
|
Die Aussage „keine nicht freigegebenen Module bauen, testen, installieren oder paketieren“ bezieht sich **nur auf Module aus `R \ S`**. Sie verbietet nicht die Tests des Entwicklerreleases. Im Gegenteil:
|
|
|
|
- Release-relevante CTests für `M` und nachgewiesene Abhängigkeiten aus `S \ M` müssen gebaut werden;
|
|
- diese CTests müssen per CTest ausgeführt werden;
|
|
- ihre Test-Binaries müssen in `qt6-release-ctest-runtime` enthalten sein;
|
|
- ihre C++-Quellen müssen in `qt6-release-ctest-sources` enthalten sein;
|
|
- die zugehörigen Testziele dürfen nicht wegen des Release-Charakters deaktiviert, entfernt, ignoriert oder aus CTest entfernt werden.
|
|
|
|
Verboten bleiben nur Tests, Targets, Quellen, Artefakte und Module aus `R \ S` sowie nicht nachgewiesene Inhalte außerhalb des Release-Scope.
|
|
|
|
Bei Unklarheiten keine Abhängigkeit raten. Unklarheit anhand realer Dateien auflösen; falls dies nicht möglich ist, Release nicht als erfolgreich melden und den Blocker exakt dokumentieren.
|
|
|
|
## 3. Repository-, Branch- und Pfadregeln
|
|
|
|
Arbeite auf dem bestehenden Branch `story/release-at-16-oct-2026`; erstelle keinen neuen Branch, außer dies ist technisch unvermeidbar und begründet. Ermittle zuerst alle Repositories, Remotes, Branches, Working Trees und Submodule und ordne jede Datei dem zuständigen Repository zu.
|
|
|
|
Aus `./qt-migration-legatus/qt6-after/qt6-migrated-legatus` dürfen nur `S` sowie unmittelbar erforderliche gemeinsame Build-/Test-/Packaging-Dateien verwendet werden, insbesondere:
|
|
|
|
- `TetraIF/`, `Z/`, `Lts/Common/`;
|
|
- `CMakeLists.txt`, `cmake/`, `tests/`, `specs/`, `include/`;
|
|
- `new_docker_build.sh`;
|
|
- tatsächlich benötigte Dockerfiles und Skripte.
|
|
|
|
Aus der Pipeline dürfen nur für diesen Release erforderliche Dateien verwendet werden, insbesondere `jenkins-ci-rme/`, `rpmbuild/make_rpm_ubuntu26.py` soweit erforderlich sowie notwendige DEB-Packaging-Dateien, Manifeste und Dockerfiles.
|
|
|
|
## 4. Build, CTest und Docker
|
|
|
|
Analysiere und passe `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh` minimal an. Der Docker-/CI-Pfad muss:
|
|
|
|
1. benötigte Systempakete reproduzierbar im Image installieren;
|
|
2. ausschließlich `S` konfigurieren und bauen;
|
|
3. echte Generator-Flows im Build-Tree ausführen;
|
|
4. alle Release-Targets einschließlich der zugehörigen CTest-Targets bauen;
|
|
5. alle Tests aus `./tests` ausführen, die `M`, `S \ M` oder erforderliche zentrale CMake-/Generator-Logik betreffen;
|
|
6. bei Build-, Link- oder Testfehlern mit Exit-Code ungleich `0` abbrechen;
|
|
7. keine Host-Pfade oder Entwicklerannahmen voraussetzen.
|
|
|
|
Tests für `R \ S` sind ausgeschlossen. Tests für `M` und nachgewiesene Tests für `S \ M` sind Pflichtbestandteil des Entwicklerreleases. Generierte Dateien bleiben im Build-Tree und werden nicht als Quellen eingecheckt.
|
|
|
|
Mindestens ausführen, sofern vorhanden:
|
|
|
|
```bash
|
|
cd ./qt-migration-legatus/qt6-after/qt6-migrated-legatus
|
|
./new_docker_build.sh
|
|
```
|
|
|
|
## 5. Getrennte DEB-Pakete
|
|
|
|
Ein einziges Sammel-DEB ist nicht zulässig. Erzeuge mindestens diese fünf getrennten Pakete mit eigenen Paketwurzeln, eigenen `DEBIAN/control`-Dateien, eigenen Allowlists und Manifesten:
|
|
|
|
1. `qt6-release-runtime-<version>.deb`
|
|
- Runtime-Binaries und Bibliotheken aus `S`;
|
|
- keine C++-Quellen und keine CTest-Quellen.
|
|
|
|
2. `qt6-release-sources-<version>.deb`
|
|
- migrierte Qt6-C++-Quellen und erforderliche Header der Module aus `S`;
|
|
- keine Qt6-Quellen aus `R \ S` und keine generierten Build-Tree-Dateien.
|
|
|
|
3. `qt6-release-ctest-runtime-<version>.deb`
|
|
- alle ausführbaren Release-relevanten CTest-Programme für `M` und nachgewiesene Teile von `S \ M`;
|
|
- erforderliche Laufzeitdateien und Testdaten;
|
|
- keine CTest-Binaries aus `R \ S`.
|
|
|
|
4. `qt6-release-ctest-sources-<version>.deb`
|
|
- C++-Quellen, Header und Testkonfiguration der enthaltenen Release-relevanten CTests;
|
|
- keine Testquellen aus `R \ S`.
|
|
|
|
5. `qt6-release-build-pipeline-<version>.deb`
|
|
- erforderliche Dockerfiles, `new_docker_build.sh`, CMake-/CTest-/Jenkins-/DEB-Packaging-Skripte, Konfigurationen und Manifeste;
|
|
- keine nicht benötigten Repository-Dateien und keine Qt6-Quellen außerhalb von `S`.
|
|
|
|
Falls ein weiteres DEB technisch erforderlich ist, dokumentiere vorab Name, Inhalt, Zweck und konkrete Dateireferenzen.
|
|
|
|
### 5.1 Verbindliches Paketierungs-Kommando
|
|
|
|
Implementiere und validiere:
|
|
|
|
```bash
|
|
./new_docker_build.sh \
|
|
--build \
|
|
--test \
|
|
--package-debs \
|
|
--deb-output "${DEB_OUTPUT_DIR}"
|
|
```
|
|
|
|
Das Kommando muss den Scope validieren, `S` einschließlich der Pflicht-CTest-Targets bauen, alle Release-relevanten CTests ausführen, bei Fehlern abbrechen, die fünf DEBs erzeugen und deren tatsächlichen Inhalt gegen die Allowlists prüfen.
|
|
|
|
Erwartete Ausgaben:
|
|
|
|
```text
|
|
${DEB_OUTPUT_DIR}/qt6-release-runtime-<version>.deb
|
|
${DEB_OUTPUT_DIR}/qt6-release-sources-<version>.deb
|
|
${DEB_OUTPUT_DIR}/qt6-release-ctest-runtime-<version>.deb
|
|
${DEB_OUTPUT_DIR}/qt6-release-ctest-sources-<version>.deb
|
|
${DEB_OUTPUT_DIR}/qt6-release-build-pipeline-<version>.deb
|
|
${DEB_OUTPUT_DIR}/manifests/*.manifest
|
|
```
|
|
|
|
### 5.2 Paketierungsregeln
|
|
|
|
- Keine unbeschränkten Verzeichnis-Globs verwenden.
|
|
- Dateien aus `R \ S` dürfen in keinem DEB enthalten sein.
|
|
- Qt6-Modulquellen dürfen nur in `qt6-release-sources` enthalten sein.
|
|
- CTest-C++-Quellen dürfen nur in `qt6-release-ctest-sources` enthalten sein.
|
|
- CTest-Binaries dürfen nur in `qt6-release-ctest-runtime` enthalten sein.
|
|
- Build-, Docker-, CI- und Packaging-Dateien dürfen nur in `qt6-release-build-pipeline` enthalten sein.
|
|
- Mehrfachzuordnungen sind nur bei technisch zwingender Notwendigkeit zulässig und zu begründen.
|
|
- Nicht benötigte Dateien werden nicht physisch gelöscht, aber zuverlässig aus allen DEBs ausgeschlossen.
|
|
- Temporäre Dateien, Logs, Host-Pfade und nicht deklarierte Build-Tree-Artefakte nicht aufnehmen.
|
|
|
|
Prüfe jedes DEB mindestens mit:
|
|
|
|
```bash
|
|
dpkg-deb --info "${deb_file}"
|
|
dpkg-deb --contents "${deb_file}"
|
|
dpkg-deb --control "${deb_file}" "${control_output_dir}"
|
|
```
|
|
|
|
Die automatisierte Prüfung muss außerdem bestätigen: gültige Metadaten, Pflichtinhalte vorhanden, Manifest entspricht exakt dem Paketinhalt, keine unerlaubten Überschneidungen, keine Inhalte aus `R \ S`, alle Pflicht-CTest-Binaries vorhanden und alle zugehörigen C++-Testquellen vorhanden.
|
|
|
|
## 6. Jenkins, RPM und Forward Declarations
|
|
|
|
Jenkins muss den Release-Scope verwenden, `new_docker_build.sh --build --test --package-debs ...` ausführen, CTest-Fehler als Pipeline-Fehler behandeln und die DEB-Erzeugung auslösen. Vorhandene RPM-Unterstützung darf den DEB-Release nicht ersetzen. `make_rpm_ubuntu26.py` nur im nachgewiesenen Umfang anpassen.
|
|
|
|
Forward Declarations dürfen nur aufgenommen werden, wenn sie nachweislich für Build oder Pflicht-CTest von `S` erforderlich sind. Dokumentiere Datei, Target und konkrete Referenz.
|
|
|
|
## 7. Scope-Audits
|
|
|
|
Vor Implementierung:
|
|
|
|
- `R`, `M`, `S` und `R \ S` vollständig ermitteln und auflisten;
|
|
- Repository-, Branch-, Remote-, Working-Tree- und Submodulestatus prüfen;
|
|
- Abhängigkeiten mit Dateireferenzen dokumentieren;
|
|
- geplante Dateien, Repository, Zweck und DEB-Zuordnung auflisten;
|
|
- sicherstellen, dass Pflicht-CTest-Binaries und C++-Testquellen eingeplant sind.
|
|
|
|
Vor Abschluss:
|
|
|
|
- Bestandsaufnahme und Audit wiederholen;
|
|
- tatsächliche DEB-Inhalte und Manifeste prüfen;
|
|
- bestätigen, dass `R \ S` weder gebaut, getestet, installiert noch paketiert wird;
|
|
- bestätigen, dass CTests von `M` und nachgewiesene CTests von `S \ M` gebaut, ausgeführt und als Quellen und Binaries ausgeliefert werden;
|
|
- keine Tests löschen, abschwächen, ignorieren oder wegen des Release-Begriffs ausschließen;
|
|
- Jenkins-, Docker-, CMake-, Installations- und Packaging-Regeln prüfen.
|
|
|
|
## 8. Finaler Bericht
|
|
|
|
Berichte kurz und faktisch:
|
|
|
|
- Status: `validiert`, `teilweise validiert` oder `blockiert`;
|
|
- Branch und Repositories/Submodule;
|
|
- vollständiges `R`, `M`, `S` und `R \ S`;
|
|
- jede Abhängigkeit aus `S \ M` mit Grund und Dateireferenz;
|
|
- Vorher-/Nachher-Scope-Audit und geänderte Dateien;
|
|
- physisch beibehaltene, aber aus DEBs ausgeschlossene Dateien;
|
|
- ausgeführte Build-, CTest-, Jenkins- und DEB-Kommandos mit Ergebnis;
|
|
- erzeugte DEBs und deren Inhalte;
|
|
- ausgeführte und ausgelieferte CTests einschließlich Binaries und C++-Quellen;
|
|
- Bestätigung, dass keine Quellen oder Artefakte aus `R \ S` enthalten sind;
|
|
- verbleibende Blocker und Risiken.
|
|
|
|
Wenn die Validierung wegen Umgebung, Docker, Zugang, Lizenz, Projekt, Jenkins, DEB-Packaging oder Pfad nicht vollständig möglich ist, klassifiziere den Blocker exakt und behaupte keinen Erfolg.
|