Chili Palmer
6e742d96b1
5.0 KiB
Purpose
Liefert geprüfte Terminal-Basic-Programme und Exportvorlagen für die vier festgelegten Ziele über Gitea Actions und Releases am bestehenden Origin aus.
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.
Scenario: Ein Ziel fehlt
- WHEN drei Zieljobs erfolgreich sind und der vierte fehlt oder fehlschlägt
- THEN wird kein vollständiger Release veröffentlicht und das fehlende Ziel bleibt erkennbar
Scenario: Normaler Commit oder Pull Request
- WHEN ein Commit auf main oder ein Pull Request gepusht wird
- THEN startet kein Actions-Build und es entstehen keine Paketartefakte
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
Scenario: Ungültiger oder unpassender Tag
- WHEN ein Tag vom Format vX.Y.Z oder von der Workspace-Version abweicht
- THEN beginnt kein Cargo-/Paketbuild; ein vom groben Tagfilter erfasster ungültiger Tag scheitert bereits in der Vorprüfung
Requirement: Nutzbare Releasearchive
Windows SHALL als .7z ausgeliefert werden; macOS und beide Linux-Architekturen SHALL jeweils als .tar.gz ausgeliefert werden. Jedes Archiv SHALL die passenden IDE-/Compiler-Executables tb/tbc und tbrt als native Runtime-/Exportvorlage (Windows jeweils mit .exe), benötigte Metadaten, Lizenz und Benutzungshinweise enthalten. Architektur, Version und Betriebssystem SHALL im Dateinamen eindeutig sein; Dateirechte und notwendige Begleitdateien SHALL erhalten bleiben.
Scenario: Aus Archiv starten
- 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.
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
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.
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