Release-Tags nach Paketbuild direkt veröffentlichen

2026-09-11 23:08:44 +02:00
1 parent 5a1a284505
commit ccc372778c
@@ -5,7 +5,7 @@ Liefert geprüfte Terminal-Basic-Programme und Exportvorlagen für die vier fest
 ## ADDED Requirements

 ### Requirement: Vier verbindliche Buildziele
-Gitea Actions am bestehenden Origin SHALL Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 aus derselben Revision auf dem vorhandenen Linux-arm64-Runner bauen und paketieren. Cross-Kompilierung SHALL für fremde Ziele verwendet werden; vier native Buildrunner MUST NOT vorausgesetzt werden. Buildprüfungen und echte Zielausführung SHALL getrennt nachvollziehbar sein. Fehlende Build- oder Ausführungsnachweise, fehlgeschlagene Tests oder fehlende Artefakte eines Pflichtziels MUST einen vollständigen erfolgreichen Release verhindern. Build, Pflichtabnahme und Paketartefakte SHALL ausschließlich durch den Push eines neuen Release-Tags im exakten Format `vX.Y.Z` ausgelöst werden; X, Y und Z SHALL nichtnegative Dezimalzahlen ohne führende Nullen sein. Der Tag SHALL der Workspace-Version entsprechen. Normale Branch-Commits und Pull Requests MUST NOT Actions-Builds oder Paketartefakte auslösen. Lokale Entwicklungsprüfungen SHALL weiterhin verfügbar sein.
+Gitea Actions am bestehenden Origin SHALL Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 aus derselben Revision auf dem vorhandenen Linux-arm64-Runner bauen und paketieren. Cross-Kompilierung SHALL für fremde Ziele verwendet werden; vier native Buildrunner MUST NOT vorausgesetzt werden. Buildprüfungen und echte Zielausführung SHALL getrennt nachvollziehbar sein. Fehlgeschlagene Builds oder fehlende Artefakte eines Pflichtziels MUST eine Veröffentlichung verhindern. Build, Paketierung und Veröffentlichung SHALL ausschließlich durch den Push eines neuen Release-Tags im exakten Format `vX.Y.Z` ausgelöst werden; X, Y und Z SHALL nichtnegative Dezimalzahlen ohne führende Nullen sein. Der Tag SHALL der Workspace-Version entsprechen. Normale Branch-Commits und Pull Requests MUST NOT Actions-Builds oder Paketartefakte auslösen. Lokale Entwicklungsprüfungen SHALL weiterhin verfügbar sein.

 #### Scenario: Ein Ziel fehlt
 - **WHEN** drei Zieljobs erfolgreich sind und der vierte fehlt oder fehlschlägt
@@ -17,7 +17,7 @@ Gitea Actions am bestehenden Origin SHALL Terminalanwendungen für Windows amd64

 #### Scenario: Neuer passender Release-Tag
 - **WHEN** v1.0.0 auf eine Revision mit Workspace-Version 1.0.0 gepusht wird
- **THEN** laufen Pflichtabnahme und anschließend die vier Paketbuilds für diese Revision
+- **THEN** laufen nach der Versionsvorprüfung die vier Paketbuilds für diese Revision und der vollständige Upload wird direkt veröffentlicht

 #### Scenario: Ungültiger oder unpassender Tag
 - **WHEN** ein Tag vom Format vX.Y.Z oder von der Workspace-Version abweicht
@@ -30,16 +30,25 @@ Windows SHALL als `.7z` ausgeliefert werden; macOS und beide Linux-Architekturen
 - **WHEN** ein Zielarchiv in ein sauberes Verzeichnis entpackt wird
 - **THEN** starten IDE und Compiler als native Terminalanwendungen und ein Beispielprojekt kann mit den mitgelieferten Vorlagen exportiert und nativ verwendet werden

-### Requirement: Tatsächliche Artefaktprüfung
-Der Actions-Releasepfad SHALL tatsächliche Prüfungen der fertig gepackten und erneut entpackten Artefakte auf dem jeweiligen Ziel verlangen. Diese SHALL als automatisierte Zielprüfungen oder dokumentierte manuelle Nachweise von separaten Prüfsystemen aus Change 05 eingebunden und vor Freigabe an die geprüfte Revision und exakte Paketprüfsumme gebunden werden. Fehlende oder nicht passende Nachweise MUST die Freigabe verhindern. Native Executables SHALL ohne TB-Installation und Quellen laufen, Library-Ausgaben SHALL mit separaten BASIC-Verbrauchern über `tbc link` ohne Library-Quellen funktionieren. Dieselbe TBL-Probe SHALL mit identischen Bytes auf allen vier Zielen verknüpft und ausgeführt werden. Library-Bau und Link-/EXE-Export SHALL mit den entpackten Tools ohne C-/Rust-Compiler oder nativen Linker beim Anwender geprüft werden; dokumentierte Systemhilfen zur EXE-Finalisierung dürfen vorhanden sein. Ein erfolgreiches Cargo-Kompilieren oder korrekt benannter Archivname MUST NOT diese Prüfung ersetzen.
+### Requirement: Lokale Paketprüfung und vorherige Entwicklungstests
+Der Release-Build SHALL Archivinhalt, Format, Zielarchitektur, Version, Revision und SHA-256 vor dem Upload lokal prüfen. Das Setzen des Release-Tags SHALL die Freigabeentscheidung des Benutzers nach dessen Entwicklungstests sein. Der Releasepfad MUST NOT eine erneute Pflichtabnahme, Ziel-/Terminalberichte, manuelle JSON-Nachweise oder einen zusätzlichen Nachweis-Commit verlangen. Vorhandene lokale Testwerkzeuge SHALL unabhängig vom Release verwendbar bleiben.

 #### Scenario: Falsches Binary im richtigen Archiv
 - **WHEN** ein Windows-amd64-Archiv versehentlich ein Binary eines anderen Ziels enthält
- **THEN** scheitert die Format-/Startprüfung vor der Veröffentlichung
+- **THEN** scheitert die Formatprüfung vor der Veröffentlichung
+
+#### Scenario: Tag ohne zusätzliche Nachweise
+- **WHEN** ein gültiger Tag gesetzt wurde und alle vier Builds sowie der vollständige Upload erfolgreich sind, ohne dass zusätzliche Nachweisdateien vorliegen
+- **THEN** veröffentlicht derselbe Workflow den Release automatisch und verlangt keinen manuellen Publish-Schritt

 ### Requirement: Nachvollziehbare Veröffentlichung
-Releaseartefakte SHALL Version/Tag, Commit, Toolchain, Buildhost, Ziel, Integritätsprüfsumme und zugehörige Prüfergebnisse nachvollziehbar machen. Nur der freigegebene Tag-/Releasepfad SHALL Veröffentlichungsrechte verwenden; Normale Commits und PRs SHALL keine Actions-Jobs starten. Der repositorygebundene Gitea-Jobtoken SHALL für Releasezugriffe nutzbar sein; ein getrenntes Secret SHALL optional bleiben. Wiederholte fehlgeschlagene Veröffentlichungen SHALL keinen bestehenden vollständigen Release stillschweigend durch unvollständige Assets ersetzen.
+Releaseartefakte SHALL Version/Tag, Commit, Toolchain, Buildhost, Ziel, Integritätsprüfsumme nachvollziehbar machen. Nur der freigegebene Tag-/Releasepfad SHALL Veröffentlichungsrechte verwenden; Normale Commits und PRs SHALL keine Actions-Jobs starten. Der repositorygebundene Gitea-Jobtoken SHALL für Releasezugriffe nutzbar sein; ein getrenntes Secret SHALL optional bleiben. Vier Archive und vier zugehörige SHA-256-Dateien SHALL die Pflichtassets bilden. Ein Entwurf SHALL ausschließlich den laufenden Upload vor Teilveröffentlichung schützen und nach dessen erfolgreicher Kontrolle im selben Job automatisch freigegeben werden. Wiederholte fehlgeschlagene Veröffentlichungen SHALL keinen bestehenden vollständigen Release stillschweigend durch unvollständige Assets ersetzen.

 #### Scenario: Paket beschädigt oder Upload unvollständig
 - **WHEN** ein Archiv nach dem Bau verändert wird oder ein Pflichtasset nicht hochgeladen werden kann
 - **THEN** verhindert die Integritäts-/Vollständigkeitsprüfung die Freigabe und nennt das betroffene Asset
+
+#### Scenario: Uploadkontrolle ohne erneuten Download
+- **WHEN** der Releasejob die lokal auf Integrität geprüften Pakete hochgeladen hat
+- **THEN** prüft er über die Release-API die vollständige Pflichtasset-Liste und die Dateigrößen, ohne Asset-Inhalte erneut herunterzuladen
+- **AND** ergänzt ein wiederholter Release-Aufruf nur fehlende Dateien; vorhandene Assets werden nicht ersetzt und abweichende Größen führen zum Fehler