TerminalBasic/docs/distribution.md

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 .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.
• 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 und Runnerlabels entsprechen dem Gitea-Modell.

Pakete und optionale lokale Zielprüfungen

terminalbasic-<version>-windows-amd64.7z sowie ...-macos-arm64.tar.gz, ...-linux-amd64.tar.gz, ...-linux-arm64.tar.gz enthalten tb/tbc im Hauptverzeichnis und runtimes/<Target-Triple>/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:

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 <tb-ui-Testexecutable> 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.