hugo/TerminalBasic
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Release-Tags nach Paketbuild direkt veröffentlichen

Browse Source
This commit is contained in:
hugo committed 2026-09-11 23:08:44 +02:00
1 parent 5a1a284505
commit ccc372778c
19 files changed
+278 -387
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

openspec/changes/phase-6-06-gitea-actions-und-releases/proposal.md
+3 -3
View File
@@ -1,6 +1,6 @@
## Why
Die vorhandenen Workflows am Gitea-Origin werden auf ausschließliche Release-Builds umgestellt. Für eine vollständige Phase 6 müssen die vier vereinbarten Zielartefakte in Gitea Actions gebaut, auf ihren Zielsystemen geprüft und als nutzbare Release-Pakete ausgeliefert werden.
Die vorhandenen Workflows am Gitea-Origin werden auf ausschließliche Release-Builds umgestellt. Für eine vollständige Phase 6 müssen die vier vereinbarten Zielartefakte in Gitea Actions gebaut, als nutzbare Release-Pakete direkt veröffentlicht werden.
## What Changes
@@ -8,8 +8,8 @@ Die vorhandenen Workflows am Gitea-Origin werden auf ausschließliche Release-Bu
- 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.
- 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.
- Lokale Testwerkzeuge für die Entwicklung erhalten. Der Benutzer testet vor dem Tag; zusätzliche Ziel-/Terminalnachweise und Nachweis-Commits sind keine Releasebedingung.
- Nach erfolgreichen vier Builds und vollständigem Upload im selben Workflow direkt veröffentlichen. Manuellen Publish-Workflow, erneute Pflichtabnahme, Nachweis-Gate und Release-Asset-Downloads entfernen; fehlgeschlagene Builds oder Uploads verhindern die Veröffentlichung.
## Capabilities