# Gitea-Build und Distribution Change 06 baut ausschließlich am Origin `git.rfc1437.de/hugo/TerminalBasic`. Die Actions verwenden das bestätigte Label `linux-arm64` und vier Zieltriple. Build, Paketierung und Veröffentlichung starten ausschließlich bei neuen Release-Tags `vX.Y.Z`, erstmals `v1.0.0`. Normale Commits und PRs starten keine CI. Tagformat und Übereinstimmung mit der Workspace-Version werden vor dem Cargo-Build geprüft; ein manueller Paketbuild ist nicht vorgesehen. Kein Cross-Build ist ein Windows-/macOS-/Linux-Emulatornachweis. ## Buildumgebung | Ziel | Builder | Fixierte Baseline | |---|---|---| | Windows amd64 | cargo-xwin 0.23.0 | VS-Kanal 17 mit festen SDK-/CRT-Versionen: SDK 10.0.26100, CRT 14.44.17.14; statische CRT | | macOS arm64 | cargo-zigbuild 0.23.0, Zig 0.16.0 | enthaltenes MacOSX11.3.sdk; Deployment Target 11.0 | | Linux amd64/arm64 | cargo-zigbuild 0.23.0, Zig 0.16.0 | glibc 2.28 | Rust 1.97.1 ist in `rust-toolchain.toml` fixiert. Die Images stehen mit Digest in `.gitea/workflows/build.yml`; SDK/Clang/Zig stammen aus diesen Images. 7-Zip 25.01 wird mit fester SHA-256 in `bootstrap.sh` bereitgestellt. Vor dem Checkout installieren die Jobs Node.js 22.22.0 mit fester SHA-256: Die Cross-Images enthalten keine Laufzeit für JavaScript-Actions. Zusätzlich prüft der Windows-Build einen festen Hash aller SDK-/CRT-Dateien und Symlinks. Änderungen unter derselben Microsoft-Versionsbezeichnung werden damit abgelehnt; der Pin muss dann ausdrücklich aktualisiert werden. Die Tabelle nennt Buildvorgaben, keine gemessenen minimalen OS-Versionen. Die tatsächliche Cross-Matrix und OS-Läufe sind im Changebericht auszuweisen. Der Builder erfordert Linux aarch64. Zwei Cargo-Buildjobs und eine sequenzielle Zielmatrix begrenzen die Last. Host-`tb-template` prüft über denselben Parser wie der Exportdienst PE32+/amd64/Console, Mach-O/arm64 oder ELF/Linux/64-Bit; fremde Executables werden beim Paketieren nicht ausgeführt. Lokaler Aufruf innerhalb des betreffenden gepinnten Containers: ```sh sh .gitea/scripts/bootstrap.sh python3 .gitea/scripts/build.py --target x86_64-pc-windows-msvc --output dist ``` Eigene native Testpakete lassen sich mit `distribution.py pack --bin-dir ... --target ... --output ... --inspector .../tb-template` erstellen. Uncommittete Quellen bleiben in `manifest.json` markiert und sind nicht freigabefähig. ## Origin-Konfiguration und Rechte Actions sind am Repository aktiviert. Der gemeinsame Runner heißt `gitea-arm64-01`. Der Benutzer hat seinen Neustartfehler behoben; die Repository-Workflows ändern keine globale Docker-/AppArmor-Konfiguration. Erforderliche Konfiguration: - Releasezugriff: standardmäßig der eingebaute repositorygebundene `gitea.token`, optional ein explizites Secret `TB_RELEASE_TOKEN`. Nur Upload/Freigabe verwenden ihn für Releasezugriffe; der Checkout speichert keine Credentials. Die tatsächliche Uploadberechtigung wird im Taglauf geprüft. Gitea 1.25 ignoriert die deklarativen `permissions`- Angaben; diese allein sind kein Nachweis getrennter Jobrechte. Siehe [Gitea-1.25-Kompatibilität](https://docs.gitea.com/1.25/usage/actions/comparison/). - Keine Branch-/PR-Trigger und kein manueller Build- oder Freigabeworkflow. Das Setzen des Release-Tags bestätigt die zuvor durchgeführten Tests. Der Release-Schritt prüft Archive, Revision und SHA-256 lokal vor dem Upload. Anschließend prüft er per Release-API die vollständige Dateiliste und die Dateigrößen, ohne die Assets erneut herunterzuladen. Wiederholungen ergänzen fehlende Dateien und ersetzen keine vorhandenen Assets; abweichende Größen führen zum Fehler. Nach vollständigem Upload veröffentlicht derselbe Job den Release direkt. Es werden keine Release-Assets erneut heruntergeladen und keine zusätzlichen Nachweise oder Secrets benötigt. Die Actions-URLs sind explizite Gitea-URLs mit festen Commit-IDs. [Absolute Action-URLs](https://docs.gitea.com/usage/actions/comparison/) und [Runnerlabels](https://docs.gitea.com/runner/) entsprechen dem Gitea-Modell. ## Pakete und optionale lokale Zielprüfungen `terminalbasic--windows-amd64.7z` sowie `...-macos-arm64.tar.gz`, `...-linux-amd64.tar.gz`, `...-linux-arm64.tar.gz` enthalten `tb`/`tbc` im Hauptverzeichnis und `runtimes//tbrt` samt `tbrt.meta` (Windows jeweils `.exe` bzw. `tbrt.exe.meta`), `LICENSE`, `INSTALL.txt` und `manifest.json`. Unix-Executables besitzen 0755. Das Manifest bindet Version, Revision, Rust, Buildhost/Image, Target und SHA-256 jeder Datei. Jedes Paket erhält zusätzlich eine `.sha256`-Datei. Für eine freiwillige lokale Zielprüfung das Paket auf dem passenden System prüfen: ```sh python3 .gitea/scripts/distribution.py target-check \ --archive /pakete/terminalbasic-1.0.0-macos-arm64.tar.gz \ --target aarch64-apple-darwin --output /nachweise/aarch64-apple-darwin ``` Das Prüfsystem braucht Python und den Prüfharness dieser Revision; die Produkte selbst laufen aus einem neu entpackten temporären Verzeichnis. Native-/TBL-Prüfungen verwenden einen leeren PATH, separate Verbraucher, keine Library-Quellen und die vorhandenen paketierten Metadaten. Auf macOS bleibt `/usr/bin/codesign` als Systemhilfe zulässig. Erzeugte Executables laufen nach Entfernen von Quellen, TBL/TBC und Vorlagen weiter. Die gemeinsame `portable.tbl` wird auf allen Zielen unverändert verwendet, SHA-256 `5d25c2f8c95ae535e55a6c84c1ddd0d964358863f4f3c780c50ac4a2eb3594df`. Windows erfordert zusätzlich `--windows-console-test ` derselben Revision. Dieses Testexecutable kann der Linux-Builder mit `cargo xwin test --locked --target x86_64-pc-windows-msvc -p tb-ui --features terminal --no-run` erzeugen; es gehört zum Prüfharness, nicht zum Anwenderpaket. DOSBox kann diese Windows-PE-Programme nicht ausführen. Windows bleibt auf Benutzerentscheidung vorerst offen. Die Bedienfolge für freiwillige Terminalprüfungen steht in `docs/plattformmatrix.md`. Ergebnisse dieser Werkzeuge sind Entwicklungsdaten und werden nicht als Releasefreigabe eingelesen. Es gibt keine Pflicht für manuelle JSON-Berichte oder einen zusätzlichen Nachweis-Commit. ## Direkte Veröffentlichung Das Setzen und Pushen eines neuen Tags `vX.Y.Z` ist die Freigabeentscheidung: Die fachlichen Tests erfolgen vorher in der Entwicklung. `build.yml` prüft Tag und Workspace-Version, baut alle vier Ziele und veröffentlicht dann acht Assets: vier Pakete und vier SHA-256-Dateien. Im Release-Build laufen keine erneute Pflichtabnahme und keine formale Ziel-/Terminalnachweisprüfung. Die vorhandenen Testwerkzeuge bleiben lokal ausführbar, beispielsweise `python3 tests/support/release-abnahme.py --vbdos-repo /pfad/zum/vbdos-bestand`. Während des Uploads bleibt der Release kurzzeitig ein Entwurf. Erst wenn alle vier Builds erfolgreich sind und Dateiliste sowie Größen stimmen, setzt derselbe Job `draft` auf false. Kein manueller Publish-Schritt und kein weiterer Commit sind erforderlich. Fehlgeschlagene Builds oder Uploads verhindern eine unvollständige Veröffentlichung. Wiederholungen ergänzen fehlende Dateien; bestehende Assets und veröffentlichte Releases werden nicht überschrieben. Tag, Paketrevision und Prüfsummen werden lokal vor dem Upload geprüft; Release-Assets werden nicht zurückgeladen.