Phase 6: P-Code-Bibliotheken und Linker abschließen, Cross-Buildplan festhalten
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
## Context
|
||||
|
||||
Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versionsabfrage liefert Gitea 1.25.4. Im Repository existieren noch keine Actions-Workflows. Runner-Verfügbarkeit, Labels und Release-Zugang wurden nicht behauptet oder verändert. Der Benutzer verlangt ausschließlich Gitea Actions am Origin und vier native Terminalziele.
|
||||
Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versionsabfrage liefert Gitea 1.25.4. Im Repository existieren noch keine Actions-Workflows. Der bestehende Runner wurde am 2026-09-07 per read-only SSH als Linux aarch64 mit laufendem Gitea-Runner-Container bestätigt. Andere Projekte am Origin verwenden bereits `linux-arm64` mit cargo-zigbuild und cargo-xwin. Das tatsächliche Label, Toolchain-/SDK-Versionen und der Release-Zugang werden bei der Anbindung dieses Projekts geprüft; eine erfolgreiche TerminalBasic-Cross-Matrix wurde noch nicht nachgewiesen. Der Benutzer verlangt ausschließlich Gitea Actions am Origin und vier native Terminalziele.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
@@ -10,19 +10,19 @@ Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versio
|
||||
|
||||
## Decisions
|
||||
|
||||
1. `.gitea/workflows/` verwendet explizite Einzel-Labels für die vier nativen Runner: Windows-amd64, macOS-arm64, Linux-amd64, Linux-arm64. Tatsächliche Labels bei Anbindung inventarisieren und dokumentieren; nicht davon ausgehen, dass mehrere Labels logisch UND bedeuten. Runner werden passend zum Ziel betrieben. Grundlage: [Gitea-1.25-Runnerdokumentation](https://docs.gitea.com/1.25/usage/actions/act-runner/).
|
||||
1. `.gitea/workflows/` nutzt den vorhandenen Linux-arm64-Runner für alle vier Build-/Paketziele. Vorhandene Workflowmuster der anderen Origin-Projekte wiederverwenden: cargo-zigbuild für Linux amd64 und macOS arm64, cargo-xwin für Windows amd64/MSVC; Linux arm64 nativ oder mit derselben festgelegten Linux-Zielbaseline. Container/Tools und benötigte SDKs/Sysroots reproduzierbar pinnen; konkrete Rust-/OS-/glibc-Versionen mit TerminalBasic prüfen. Das Runnerlabel `linux-arm64` bei Anbindung bestätigen. Vier native Buildrunner sind nicht erforderlich. `build-runtime.py` erzeugt Vorlagenmetadaten mit dem Hostwerkzeug für das jeweilige Target; fremde Executables werden auf dem Buildhost nicht nativ ausgeführt.
|
||||
2. Wiederverwendbare Repository-Skripte erledigen Build, Tests, Paketierung und Prüfung auch lokal. Source-Checkout vom Gitea-Origin, alle zusätzlichen Actions nur über explizite Gitea-URLs und feste Revisionen, soweit überhaupt nötig; keine implizite fremde Action-Auflösung. Rust und benötigte Systemwerkzeuge versioniert bereitstellen. Server-/Runner-Kompatibilität praktisch prüfen, statt lediglich YAML zu validieren.
|
||||
3. Matrixprodukte: `terminalbasic-<version>-windows-amd64.7z`, `terminalbasic-<version>-macos-arm64.tar.gz`, `terminalbasic-<version>-linux-amd64.tar.gz`, `terminalbasic-<version>-linux-arm64.tar.gz`. Windows enthält `tb.exe`/`tbc.exe`/`tbrt.exe`, übrige `tb`/`tbc`/`tbrt`; tbrt ist die native Exportvorlage, dazu deren Metadaten, Lizenz, Kurzinstallation. Archive dürfen keine Buildverzeichnis-/Quellbaumabhängigkeiten haben. Exportierte Anwenderprogramme bleiben normale native Einzelartefakte; die Archivformate betreffen die Distribution.
|
||||
4. Windows nutzt 7-Zip zum Erzeugen/Prüfen, Unix tar+gzip unter Erhalt der Executable-Bits. Jobs entpacken das fertige Archiv in ein neues Verzeichnis und führen die darin liegenden Tools aus. Ein gemeinsames TBL-Testartefakt wird einmal erzeugt und mit nachgewiesen identischen Bytes auf allen vier Zieljobs verwendet. Separate BASIC-Verbraucher werden mit den entpackten TB-Tools verknüpft, als TBC ausgeführt und mit tbrt als EXE exportiert. Library-Quellen sind dabei nicht verfügbar. Erzeugung/Linken werden in einer Umgebung ohne erreichbaren C-/Rust-Compiler oder nativen Linker geprüft; Systemhilfen zur EXE-Finalisierung dürfen verfügbar bleiben. Fertige EXEs laufen anschließend ohne externe TBL/TBC oder TB-Installation.
|
||||
5. In jedem Zieljob `cargo test --workspace`; Clippy/Formatprüfung zentral mit passender Toolchain, native Tests aus 02/03/04 und automatisierbare Plattformtests aus 05 auf ihren tatsächlichen Zielen. Den fixierten Fremdprogrammbestand ausdrücklich im erforderlichen Abnahmelauf bereitstellen. Compile-/VM-Messungen auf dokumentiertem Referenzrunner statt instabiler Debug-Zeitlimits in allen Jobs.
|
||||
6. Gitea-Release erst nach allen Pflichtjobs und Vollständigkeits-/Prüfsummenprüfung freigeben. Upload zunächst zu einem als Entwurf erkennbaren Release oder gleichwertigem nicht freigegebenen Staging; anschließend atomare Freigabe im Rahmen der verfügbaren API. PR-Jobs ohne Veröffentlichungsrechte und ohne Release-Secrets; fremder PR-Code darf nicht mit solchen Rechten auf persönlichen Runnern laufen. Zugangswerte werden als Gitea-Secrets konfiguriert, nicht committed. Tests erzeugen keine öffentlichen Testreleases.
|
||||
4. Der Linux-Buildhost erzeugt/prüft Windows-Archive mit 7-Zip und Unix-Archive mit tar+gzip unter Erhalt der Executable-Bits. Inhalts-/Formatprüfungen laufen dort; tatsächliche Start-/Exportprüfungen verwenden neu entpackte Pakete auf passenden Zielsystemen aus 05, automatisiert oder dokumentiert manuell. Externe Nachweise müssen an Revision und exakte Paketprüfsumme gebunden und vor Freigabe geprüft sein. Ein gemeinsames TBL-Testartefakt wird einmal erzeugt und mit nachgewiesen identischen Bytes auf allen vier Zielsystemen verwendet. Separate BASIC-Verbraucher werden mit den entpackten TB-Tools verknüpft, als TBC ausgeführt und mit tbrt als EXE exportiert. Library-Quellen sind dabei nicht verfügbar. Erzeugung/Linken werden in einer Umgebung ohne erreichbaren C-/Rust-Compiler oder nativen Linker geprüft; Systemhilfen zur EXE-Finalisierung dürfen verfügbar bleiben. Fertige EXEs laufen anschließend ohne externe TBL/TBC oder TB-Installation.
|
||||
5. `cargo test --locked --workspace`, Clippy und Formatprüfung zentral auf dem Linux-arm64-Host; zielabhängige Rust-Testprogramme bei Bedarf cross-kompilieren und auf passenden Prüfsystemen ausführen. Native Tests aus 02/03/04 und automatisierbare Plattformtests aus 05 auf ihren tatsächlichen Zielen ausführen. Buildstatus und Ausführungsnachweise getrennt ausweisen; macOS-EXE-Finalisierung mit codesign erfolgt auf macOS. Den fixierten Fremdprogrammbestand ausdrücklich im erforderlichen Abnahmelauf bereitstellen. Compile-/VM-Messungen auf dokumentiertem Referenzrunner statt instabiler Debug-Zeitlimits in allen Jobs.
|
||||
6. Gitea-Release erst nach allen Pflichtjobs, zugeordneten echten Zielnachweisen und Vollständigkeits-/Prüfsummenprüfung freigeben. Upload zunächst zu einem als Entwurf erkennbaren Release oder gleichwertigem nicht freigegebenen Staging; anschließend atomare Freigabe im Rahmen der verfügbaren API. PR-Jobs ohne Veröffentlichungsrechte und ohne Release-Secrets; fremder PR-Code darf nicht mit solchen Rechten auf persönlichen Runnern laufen. Zugangswerte werden als Gitea-Secrets konfiguriert, nicht committed. Tests erzeugen keine öffentlichen Testreleases.
|
||||
7. README-/PLAN-/Releasehinweise nennen die tatsächlich gemessenen minimalen OS-/Systembibliotheksversionen. Developer-ID-/öffentliche Vertrauenssignatur ist kein Ersatz für lokale Ausführbarkeit; wenn entsprechende Identitäten nicht konfiguriert sind, deren Download-/Vertrauensgrenzen ehrlich dokumentieren. Mac-Artefakte müssen trotzdem lokal korrekt finalisiert und startbar sein.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- Native Runner fehlen → explizite Bereitstellungsaufgabe und fehlender Zieljob verhindern Abschluss; Workflowdateien allein sind kein CI-Nachweis.
|
||||
- Cross-Toolchain/SDK fehlt oder ist inkompatibel → Buildbootstrap korrigieren und echte Vierzielpakete nachweisen. Fehlende Zielausführung auf Prüfsystemen sperrt weiterhin Abschluss/Release; erfolgreiche Cross-Builds allein reichen nicht.
|
||||
- Vorlagen passen nicht zum Tool → Manifest-/Prüfsummen-/Versionscheck und Export aus entpacktem Paket.
|
||||
- Plattformwerkzeuge variieren → Zieljob prüft tatsächliche 7z-/tar-/Rust-Build-/Signierwerkzeuge; keine stillen Ersatzformate.
|
||||
- Plattformwerkzeuge variieren → Buildhost prüft Archiv-/Cross-Werkzeuge, Prüfsysteme prüfen benötigte Signierwerkzeuge; keine stillen Ersatzformate.
|
||||
- Fehler beim Upload → vollständige Pflichtasset-Liste vor Freigabe prüfen; bestehende vollständige Releases nicht beschädigen.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
@@ -5,10 +5,11 @@ Das Repository am bestehenden Gitea-Origin enthält noch keine CI-/Release-Workf
|
||||
## What Changes
|
||||
|
||||
- Gitea Actions am bestehenden Origin für Push-/PR-Prüfungen und taggebundene Releases einrichten.
|
||||
- Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 bauen; keine zusätzlichen Zielplattformen und kein Mirror.
|
||||
- Auf dem vorhandenen Linux-arm64-Gitea-Runner Terminalanwendungen für Windows amd64 (cargo-xwin), macOS arm64 und Linux amd64 (cargo-zigbuild) sowie Linux arm64 bauen; keine zusätzlichen Zielplattformen und kein Mirror.
|
||||
- Windows als `.7z`, macOS und beide Linux-Ziele als `.tar.gz` mit `tb`, `tbc` und der nativen `tbrt`-Vorlage samt Metadaten paketieren.
|
||||
- Entpackte Pakete einschließlich `tbc link`, nativer Exporte und separater BASIC-Verbraucher von `.tbl` prüfen, Prüfsummen und nachvollziehbare Buildmetadaten liefern.
|
||||
- Releases erst nach vollständigen erforderlichen Prüfungen veröffentlichen; fehlende Runner oder Assets dürfen keinen grünen vollständigen Release ergeben.
|
||||
- Echte Zielausführung aus 05 getrennt vom Cross-Bau einbinden, automatisiert oder als revisions-/paketprüfsummengebundenen Nachweis von separaten Prüfsystemen. Vier native Buildrunner werden nicht vorausgesetzt.
|
||||
- Releases erst nach vollständigen erforderlichen Prüfungen veröffentlichen; fehlende Zielnachweise oder Assets dürfen keinen grünen vollständigen Release ergeben.
|
||||
|
||||
## Capabilities
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ Liefert geprüfte Terminal-Basic-Programme und Exportvorlagen für die vier fest
|
||||
## 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 bauen und prüfen. Fehlende Runner, fehlgeschlagene Tests oder fehlende Artefakte eines Pflichtziels MUST einen vollständigen erfolgreichen Release verhindern. Für normale Änderungen SHALL ein reproduzierbarer Build-/Teststatus vorliegen.
|
||||
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. Für normale Änderungen SHALL ein reproduzierbarer Build-/Teststatus vorliegen.
|
||||
|
||||
#### Scenario: Ein Ziel fehlt
|
||||
- **WHEN** drei Zieljobs erfolgreich sind und der vierte fehlt oder fehlschlägt
|
||||
@@ -19,14 +19,14 @@ Windows SHALL als `.7z` ausgeliefert werden; macOS und beide Linux-Architekturen
|
||||
- **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
|
||||
Die Actions SHALL die fertig gepackten und erneut entpackten Artefakte auf dem jeweiligen Ziel testen. 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.
|
||||
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, Ziel, Integritätsprüfsumme und zugehörige Prüfergebnisse nachvollziehbar machen. Nur der freigegebene Tag-/Releasepfad SHALL Veröffentlichungsrechte verwenden; PR-Prüfungen MUST keine Release-Secrets benötigen. Wiederholte fehlgeschlagene Veröffentlichungen SHALL keinen bestehenden vollständigen Release stillschweigend durch unvollständige Assets ersetzen.
|
||||
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; PR-Prüfungen MUST keine Release-Secrets benötigen. 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
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
## 1. Gitea und Runner
|
||||
|
||||
- [ ] 1.1 Verfügbare Gitea-1.25-kompatible Runner und Labels für Windows amd64, macOS arm64, Linux amd64/arm64 inventarisieren und fehlende Zielrunner anbinden; ein kleiner Gitea-Prüfjob muss tatsächliches OS/Architektur je Ziel nachweisen.
|
||||
- [ ] 1.2 Repositorylokale Build-/Testaufrufe und feste Toolchain-/Systemvoraussetzungen bereitstellen; jeder Aufruf muss lokal auf seinem Ziel mit --locked bauen und erforderliche Regressionen starten können.
|
||||
- [ ] 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. Ein Gitea-Prüfjob muss den Buildhost nachweisen; separate echte Prüfsysteme aus 05 zuordnen, 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 Push-/PR-Workflow unter .gitea/workflows anbinden; ein tatsächlicher Origin-Lauf muss vier Zielergebnisse und Fehlerstatus liefern, ohne Release-Secrets im PR-Pfad.
|
||||
|
||||
## 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 Jedes fertige Paket neu entpacken und die enthaltenen Programme starten; `tbc link` und EXE-/TBL-Beispiele müssen mit separaten BASIC-Verbrauchern ohne Library-Quellen/Entwicklungscheckout sowie ohne erreichbaren C-/Rust-Compiler oder nativen Linker funktionieren.
|
||||
- [ ] 2.3 Jedes fertige Paket auf dem tatsächlichen Ziel neu entpacken und die enthaltenen Programme starten; automatisierte oder dokumentiert manuelle Nachweise aus separaten Prüfsystemen an Revision und Paketprüfsumme binden; `tbc link` und EXE-/TBL-Beispiele müssen mit separaten BASIC-Verbrauchern ohne Library-Quellen/Entwicklungscheckout sowie ohne erreichbaren C-/Rust-Compiler oder nativen Linker funktionieren.
|
||||
- [ ] 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 Taggebundenen Gitea-Releasepfad mit vollständiger Pflichtasset-Liste und getrennten Rechten einrichten; fehlgeschlagene/fehlende Zieljobs müssen die Freigabe verhindern.
|
||||
- [ ] 3.1 Taggebundenen Gitea-Releasepfad mit vollständiger Pflichtasset-Liste und getrennten Rechten einrichten; fehlgeschlagene/fehlende Zielbuilds oder zugeordnete echte Paket-/Zielprüfungen müssen die Freigabe verhindern.
|
||||
- [ ] 3.2 Upload zunächst als nicht freigegebenen Stand prüfen und erst vollständig freigeben; ein simulierter fehlender Upload darf keinen vollständigen bestehenden Release überschreiben.
|
||||
- [ ] 3.3 Fremdprogramm-, Inventar-, native und automatisierte Plattformnachweise sowie Referenzbenchmarks in den erforderlichen Abnahmelauf integrieren; ignorierte Pflichtfälle müssen als fehlend sichtbar bleiben.
|
||||
- [ ] 3.4 Einen tatsächlichen vollständigen Gitea-Lauf mit vier Paketartefakten nachweisen; Run-/Commit-/Targetdaten und entpackte Prüfergebnisse an 07 übergeben, bevor der Change als fertig gilt.
|
||||
- [ ] 3.4 Einen tatsächlichen vollständigen Gitea-Lauf mit vier Paketartefakten nachweisen; Run-/Commit-/Buildhost-/Targetdaten und paketprüfsummengebundene entpackte Prüfergebnisse an 07 übergeben, bevor der Change als fertig gilt.
|
||||
|
||||
Reference in New Issue
Block a user