133 lines
7.2 KiB
Markdown
133 lines
7.2 KiB
Markdown
# 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-<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:
|
|
|
|
```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 <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.
|