3.1 KiB
3.1 KiB
1. Gitea und Runner
- 1.1 Vorhandenen Linux-arm64-Gitea-Runner und tatsächliches Label bestätigen; Cross-Buildumgebungen mit cargo-zigbuild, cargo-xwin und benötigten SDKs/Sysroots reproduzierbar festlegen. Den Buildhost bestätigen, ohne vier native Buildrunner vorauszusetzen.
- 1.2 Repositorylokale Build-/Testaufrufe und feste Toolchain-/Systemvoraussetzungen bereitstellen; alle vier Ziele müssen auf Linux arm64 mit --locked baubar sein. Zentrale Workspace-Regressionen und getrennte Aufrufe für echte Zielprüfungen bereitstellen; fremde Executables nicht als nativ auf dem Buildhost getestet ausweisen.
- 1.3 Workflow ausschließlich für neue Release-Tags vX.Y.Z anbinden; normale Commits/PRs dürfen keine Jobs oder Artefakte starten. Tagformat und Workspace-Version vor Cargo prüfen; tatsächlichen Taglauf mit vier Zielergebnissen und Fehlerstatus nachweisen.
2. Artefakte und Pakete
- 2.1 IDE, CLI und native
tbrt-Exportvorlage je Ziel in Gitea Actions bauen; Format-/Architektur-/Versionsprüfungen müssen Windows amd64, macOS arm64 und beide Linux-Architekturen eindeutig bestätigen. - 2.2 Windows-Paket als .7z und macOS-/Linux-Pakete als .tar.gz erzeugen; Archivtests müssen Dateinamen, Paketinhalt, Executable-Rechte und notwendige Begleitdateien prüfen.
- 2.3 Vorhandene lokale Ziel-/Export-/Library-Prüfwerkzeuge für die Entwicklung erhalten; ihre Berichte sind keine Voraussetzung der Veröffentlichung. Linux-/Windows-Ausführung und vollständige Terminalfolgen bleiben auf Benutzerentscheidung zurückgestellt.
- 2.4 Einmal erzeugte TBL-Probe mit identischen Bytes an alle vier Zielprüfungen verteilen sowie Artefaktmanifest und Prüfsummen erzeugen; absichtlich beschädigte oder vertauschte Zielartefakte müssen die Prüfung scheitern lassen.
3. Releasepfad
- 3.1 Nach erfolgreichen vier Builds und vollständigem Upload direkt im selben Workflow veröffentlichen; ein gültiges Tag bestätigt die vorherigen Benutzertests. Jobtoken verwenden, keine manuelle Freigabe oder zusätzlichen Nachweis-Commits verlangen.
- 3.2 Upload vorübergehend als Entwurf führen, per API-Dateiliste und Größen ohne erneuten Asset-Download prüfen und danach automatisch veröffentlichen; ein simulierter fehlender Upload darf keinen vollständigen bestehenden Release überschreiben.
- 3.3 Manuellen Publish-Workflow, Nachweis-Gate, Asset-Downloadpfade und erneute Pflichtabnahme aus dem Release-Build entfernen; lokale Testwerkzeuge erhalten.
- 3.4 Einen tatsächlichen Taglauf mit vier Paketbuilds und automatischer Veröffentlichung des vollständigen Releases bestätigen; Run-/Commit-/Targetdaten an 07 übergeben.
Entscheidung 11.09.2026: Der Release-Tag ist die Freigabe nach vorherigen Benutzertests. Die bisher verlangten externen Nachweis-Commits und manuelle Freigabe entfallen. Die lokalen Testwerkzeuge bleiben erhalten. Lauf 7 belegt die vier Tagbuilds; die direkte Veröffentlichung nach der Umstellung ist noch in einem neuen Taglauf zu bestätigen. Historische Protokolle sind weiter unter evidence/ und in verification.md abgelegt.