31 lines
4.9 KiB
Markdown
31 lines
4.9 KiB
Markdown
## 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.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:** In Actions erzeugte, geprüfte und vollständig paketierte Zielartefakte; nachvollziehbare Gitea-Releases.
|
|
|
|
**Non-Goals:** Repository-Mirror, zweite CI-Plattform, Installer-/GUI-Produkt, reine Cross-Compile-Ergebnisse als native Abnahme.
|
|
|
|
## 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/).
|
|
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.
|
|
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.
|
|
- 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.
|
|
- Fehler beim Upload → vollständige Pflichtasset-Liste vor Freigabe prüfen; bestehende vollständige Releases nicht beschädigen.
|
|
|
|
## Migration Plan
|
|
|
|
Lokale Skripte zuerst lauffähig machen, dann Gitea-Runner und Workflows anbinden. PR-/Push-Lauf ohne Veröffentlichung prüfen; kontrollierter Tag-/Release-Lauf nach erfolgreicher Matrix. Bisherige lokale Cargo-Nutzung erhalten. Rollback über vorheriges vollständiges Release und Rücknahme der Workflowänderung; keine Server-/Runnerinstallation durch bloße Proposal-Erstellung.
|