release: één commando dat lokaal voorbereidt → CI bewaakt → verspreidt (met monotone tag-guard)

brenno commented

2026-08-03 12:28:13 +00:00

Owner

Aanleiding

Bij het snijden van een release viel op dat er een update-notificatie voor MASWE
klaarstond (make catalogs-outdated / de adviserende check in
scripts/build_release.sh). Zo'n melding hoort niet vlak vóór een release te worden
ontdekt en dan met de hand te worden weggewerkt — precies dat soort verrassingen wil je
uit het releaseproces halen. De basisregel is: staat er een hogere upstream-versie, dan
wordt die bijgewerkt, niet genoteerd (zie de werkwijze rond
make check-pins / make deps-outdated / make catalogs-outdated).

Breder: het releaseproces bestaat nu uit een reeks losse, met de hand uitgevoerde
stappen in een vaste volgorde. Dat werkt, maar het is elke keer handwerk en dus elke
keer nét iets anders. De wens is: één commando dat het hele proces volgtijdelijk en
identiek uitvoert, zodat je alleen nog de uitkomst hoeft te bewaken en het ook zelf
vanaf de commandoregel kunt draaien.

Doel

Eén orkestrerend commando (bijv. make release TAG=v0.2.1 of
scripts/release.sh v0.2.1) dat het volledige proces volgtijdelijk afdraait:

eerst het lokale werk — bijwerken, controleren, bouwen, tekenen;
pas als álles lokaal groen is, doorgaan naar de CI-straat (de tag pushen);
de remote release bewaken (eens per minuut pollen) tot die klaar is;
pas als CI klaar is, de verspreiding doen — inclusief de website van LibreKAT
en het minisign-tekenen van het manifest;
lokaal ook de systeemversie in de application-directory vervangen.

Zelfde proces, elke keer. Menselijke rol = de uitkomst bewaken en de handmatige
vertrouwenspunten bevestigen (Developer-ID/notarisatie-wachtwoorden, minisign-wachtwoord).

Huidige situatie (uitgangspunt — dit bestaat al en moet worden geörkestreerd, niet herbouwd)

De release draait vandaag op één v*-tag. De keten en het "waarom waar" staan in
docs/BUILD.md § Cutting a release. Kort in kaart:

Vóór de tag, met de hand (de "lokale fase" die nu impliciet is):

make check-release groen op main (= make check-full als harde poort + adviserende
ZAP/DAST-scan van de live host). Ook make linux-gate en een blik op open
security/privacy-issues.
make catalogs-outdated — de MASWE/WSTG/MASTG/CWE-check die de aanleiding was.
Versie bijwerken op vier plekken die samen moeten kloppen (anders faalt een test of
de sbom-freshness):
- pubspec.yaml → version: (bron van de waarheid; nu 0.2.0+5),
- lib/services/export_metadata.dart → kOciDeckVersion (bewaakt door
  test/version_consistency_test.dart),
- CHANGELOG.md → de ## [x.y.z] — unreleased-kop wordt versie + datum,
- make sbom opnieuw (root-componentversie; anders faalt de sbom-freshness-poort).
Tag zetten en pushen naar origin (forge) én mirror (GitHub) — de mirror is nodig
omdat de Windows-build daar draait en als release-asset terugkomt.

Op de tag, in CI (.forgejo/workflows/release.yml):

jobs: web, deploy-web (opt-in via secrets), linux, macos (tekent + notariseert op
mac-brenno met keychain-items), windows-ophalen (wacht tot 45 min op de GitHub-mirror-asset),
publiceren (bundelt alles + SHA256SUMS), website-downloads (draait
scripts/bump-ocideck.sh <versie> in de website-repo + ./publiceersite).

Ná de tag, met de hand (lokaal, bewust off-runner):

make sign-release SHA256SUMS=… → minisign detached signature over SHA256SUMS
(privésleutel ~/.minisign/ocideck-release.key, mét wachtwoord — mag nooit een
runner-secret worden), SHA256SUMS.minisig aan de release hangen.
Eventueel make deploy-web als de deploy-secrets niet gezet zijn (nu het geval:
gebruiker deployt zelf).

Relevante bouwstenen die al bestaan:

scripts/build_release.sh (make build-release) — bouwt web + macOS lokaal, mét de
adviserende catalogs-check ervóór.
scripts/sign_release.sh (make sign-release) — minisign.
scripts/notarize_macos.sh (make notarize-macos) — Developer-ID + notarisatie, lokaal.
scripts/deploy_web.sh (make deploy-web) — geharde webbundel live (verify → atomic swap → verify).
make refresh-catalogs — regenereert WSTG/MASTG/MASWE (bewust buiten make check).

Voorgestelde opzet

Eén commando met een tag-argument, dat drie fasen strikt volgtijdelijk draait en bij
elke faalstap stopt (set -Eeuo pipefail-discipline). Voorstel voor de naam:
make release TAG=v0.2.1 (dun laagje over scripts/release.sh).

Fase 1 — Lokaal voorbereiden (alles móét groen vóór de tag)

Tag-guard. Valideer TAG (semver, v-prefix) en controleer dat hij strikt hoger
is dan de laatst uitgebrachte versie (git tag --sort=-creatordate / hoogste v*).
Nooit gelijk of lager. Weiger anders, zonder iets te wijzigen.
Updates laden en wegwerken vóór het bouwen. Draai de verouderingschecks
(make catalogs-outdated, make deps-outdated, make check-pins) en werk bij wat
bijgewerkt moet worden (dit is de MASWE-aanleiding). Bij een gevonden hogere versie:
make refresh-catalogs en de versies in lib/services/reference_standards.dart
spiegelen, resp. de deps/pins bijwerken — conform de "hogere versie = overal bijwerken"-regel.
Ontwerpvraag: volledig automatisch bijwerken, of stoppen-met-melding zodat de mens
beslist? (catalogs is bewust adviserend gehouden; zie ontwerpvragen onderaan.)
Versie doorzetten op de vier plekken: pubspec.yaml, kOciDeckVersion,
CHANGELOG.md-kop (unreleased → versie + datum), en make sbom opnieuw.
Volledige poort groen: make check-release (+ make linux-gate). Faalt er iets,
dan stopt het proces hier — er wordt niets gepusht.
Lokaal bouwen + tekenen wat lokaal moet: make build-release, en op deze machine
het macOS-tekenen/notariseren (make notarize-macos) — de release-signing gebeurt
op deze machine. Verifieer het zegel (codesign --verify --deep --strict; let op de
schone-build-valkuil: flutter clean vóór een build die je installeert).
Systeemversie vervangen in de application-directory. Kopieer de vers gebouwde,
geverifieerde .app naar /Applications (eerst de draaiende app afsluiten; toets op
pgrep, niet op de exitstatus van osascript quit). Alleen als het zegel groen is —
een kapot zegel reist mee door ditto.

Fase 2 — Naar de CI-straat en bewaken

Tag zetten en pushen naar origin (forge) én mirror (GitHub). Pas hier — geen
tag zolang fase 1 niet volledig groen is.
Remote bewaken, eens per minuut. Poll de forge-run tot alle release-jobs klaar zijn
(web, linux, macos, windows-ophalen, publiceren, eventueel deploy-web en
website-downloads). Gebruik de REST-route die op deze instance wél werkt:
GET /releases?limit=N + filter op tag_name voor de release, en de
actions/runs/{id}/jobs → jobs/{jobId}/logs-route voor jobstatus/logs.
Let op de bekende valkuilen: GET /releases/tags/{tag} is onbetrouwbaar op deze
instance (gebruik de lijst), en een al-gepushte v*-tag mag je nooit verplaatsen
(mislukte release → nieuwe patch-tag, niet hertaggen — anders degradeert de
mirror-Windows-release tot draft en blijft windows-ophalen eeuwig wachten).

Fase 3 — Verspreiden (pas ná groene CI)

Manifest tekenen: SHA256SUMS ophalen uit de gepubliceerde release,
make sign-release, SHA256SUMS.minisig terughangen.
Website van LibreKAT meenemen. In principe doet de website-downloads-job dit al
op de tag (scripts/bump-ocideck.sh <versie> + ./publiceersite). De orkestrator moet
dit bewaken en, bij overslaan/falen, de handmatige terugval draaien in de
website-repo. Zie ontwerpvraag over dubbeling met de bestaande job.
Web live waar dat (nog) niet automatisch gaat: make deploy-web (zolang de
deploy-secrets niet gezet zijn deployt de gebruiker zelf — dit punt respecteren, niet
eigenmachtig overrulen).

Detaileisen (expliciet gevraagd)

Tag-argument met monotone guard: de nieuwe versie mag nooit lager of gelijk
zijn dan de vorige. Harde stop, geen wijzigingen, duidelijke melding.
macOS release-signing op deze machine (Developer-ID + notarisatie, keychain-items;
privésleutels blijven lokaal, nooit als runner-secret).
CI-bewaking eens per minuut; verspreiding start pas als CI klaar is.
LibreKAT-website hoort bij de verspreiding.
Lokaal de systeemversie in de application-directory vervangen (/Applications).
Elke faalstap stopt de keten; niets half doen. Idempotent waar mogelijk (herstart na een
gefaalde stap moet veilig zijn).

Ontwerpvragen / aandachtspunten

Verhouding tot de bestaande tag-gedreven pipeline. Nu triggert de tag de hele
CI-keten inclusief website-downloads en (opt-in) deploy-web. De gevraagde orkestrator
zet lokaal-eerst en doet verspreiding "pas na CI". Er zit dus overlap: doet de
orkestrator de website/deploy zélf, of bewaakt hij alleen de CI-jobs die dat al doen
en springt hij alleen bij als die overslaan/falen? Voorkeur lijkt: CI blijft de bron,
orkestrator bewaakt + vult de handmatige gaten (minisign, /Applications, eventuele
handmatige web-deploy). Vast te leggen vóór bouwen.
Automatisch bijwerken vs. beslissen. De catalogs-check is bewust adviserend (een
nieuwe upstream-versie is een afweging, geen defect, en het bijwerken verandert waar een
rapport naar verwijst). "Alles automatisch bumpen in het releaseproces" botst daarmee.
Waarschijnlijk juiste vorm: de orkestrator stopt met een duidelijke melding als er
iets bij te werken valt, doet het bijwerken als aparte, bevestigde stap, en gaat dan
opnieuw door de poort — niet stilzwijgend meebumpen tijdens een release.
Interactieve vertrouwenspunten. Notarisatie-wachtwoord en minisign-wachtwoord zijn
interactief. Het "één commando"-ideaal mag die niet omzeilen; het commando moet er netjes
om vragen op het juiste moment (of duidelijk pauzeren).
Waar leeft dit? Eén scripts/release.sh met een dunne make release TAG=…-wrapper
ligt voor de hand (consistent met build_release.sh/sign_release.sh). De CI-kant
(release.yml) is grotendeels al af; de wens raakt vooral de lokale orkestratie +
bewaking, niet zozeer nieuwe CI-jobs. Documenteren in docs/BUILD.md.
Bewakingsroute robuust maken. De REST-valkuilen (onbetrouwbare /releases/tags/{tag},
job-log-route) horen in het script afgevangen, niet elke keer opnieuw ontdekt.

Acceptatiecriteria

Eén commando met tag-argument draait fase 1→2→3 volgtijdelijk en stopt bij de eerste fout.
Tag-guard weigert een versie die niet strikt hoger is dan de vorige, zonder wijzigingen.
Verouderingschecks (MASWE c.s.) worden aan het begin gedraaid en op de afgesproken
manier afgehandeld (bijwerken of gecontroleerd stoppen).
Versie wordt op alle vier de plekken consistent doorgezet; make check-release groen
vóór de tag.
macOS-tekenen/notariseren lokaal, met zegelverificatie; de nieuwe .app vervangt de
versie in /Applications.
Tag naar forge + mirror; CI wordt eens per minuut bewaakt tot klaar.
Verspreiding pas ná groene CI: minisign-manifest, LibreKAT-website bijgewerkt en live,
web live (of expliciet aan de gebruiker gelaten zolang dat de afspraak is).
Werkwijze en valkuilen gedocumenteerd in docs/BUILD.md; een tool/-poort of test
dekt de tag-guard (een bugfix/gedragsregel krijgt een toets).

Raakvlakken (bestanden)

scripts/build_release.sh, scripts/sign_release.sh, scripts/notarize_macos.sh,
scripts/deploy_web.sh, Makefile (release-targets), .forgejo/workflows/release.yml,
pubspec.yaml, lib/services/export_metadata.dart, CHANGELOG.md, sbom/,
lib/services/reference_standards.dart (+ make refresh-catalogs), de website-repo
(scripts/bump-ocideck.sh, ./publiceersite), docs/BUILD.md.

## Aanleiding Bij het snijden van een release viel op dat er een **update-notificatie voor MASWE** klaarstond (`make catalogs-outdated` / de adviserende check in `scripts/build_release.sh`). Zo'n melding hoort niet vlak vóór een release te worden ontdekt en dan met de hand te worden weggewerkt — precies dat soort verrassingen wil je uit het releaseproces halen. De basisregel is: staat er een hogere upstream-versie, dan wordt die **bijgewerkt**, niet genoteerd (zie de werkwijze rond `make check-pins` / `make deps-outdated` / `make catalogs-outdated`). Breder: het releaseproces bestaat nu uit een reeks losse, met de hand uitgevoerde stappen in een vaste volgorde. Dat werkt, maar het is elke keer handwerk en dus elke keer nét iets anders. De wens is: **één commando** dat het hele proces volgtijdelijk en identiek uitvoert, zodat je alleen nog de **uitkomst hoeft te bewaken** en het ook zelf vanaf de commandoregel kunt draaien. ## Doel Eén orkestrerend commando (bijv. `make release TAG=v0.2.1` of `scripts/release.sh v0.2.1`) dat het volledige proces volgtijdelijk afdraait: 1. **eerst het lokale werk** — bijwerken, controleren, bouwen, tekenen; 2. **pas als álles lokaal groen is**, doorgaan naar de **CI-straat** (de tag pushen); 3. de remote release **bewaken** (eens per minuut pollen) tot die klaar is; 4. **pas als CI klaar is**, de **verspreiding** doen — inclusief de website van LibreKAT en het minisign-tekenen van het manifest; 5. lokaal ook de **systeemversie in de application-directory vervangen**. Zelfde proces, elke keer. Menselijke rol = de uitkomst bewaken en de handmatige vertrouwenspunten bevestigen (Developer-ID/notarisatie-wachtwoorden, minisign-wachtwoord). ## Huidige situatie (uitgangspunt — dit bestaat al en moet worden geörkestreerd, niet herbouwd) De release draait vandaag op **één `v*`-tag**. De keten en het "waarom waar" staan in `docs/BUILD.md` § *Cutting a release*. Kort in kaart: **Vóór de tag, met de hand (de "lokale fase" die nu impliciet is):** - `make check-release` groen op `main` (= `make check-full` als harde poort + adviserende ZAP/DAST-scan van de live host). Ook `make linux-gate` en een blik op open `security`/`privacy`-issues. - `make catalogs-outdated` — de MASWE/WSTG/MASTG/CWE-check die de aanleiding was. - Versie bijwerken op **vier** plekken die samen moeten kloppen (anders faalt een test of de sbom-freshness): - `pubspec.yaml` → `version:` (bron van de waarheid; nu `0.2.0+5`), - `lib/services/export_metadata.dart` → `kOciDeckVersion` (bewaakt door `test/version_consistency_test.dart`), - `CHANGELOG.md` → de `## [x.y.z] — unreleased`-kop wordt versie + datum, - `make sbom` opnieuw (root-componentversie; anders faalt de sbom-freshness-poort). - Tag zetten en pushen naar **origin (forge)** én **mirror (GitHub)** — de mirror is nodig omdat de Windows-build daar draait en als release-asset terugkomt. **Op de tag, in CI (`.forgejo/workflows/release.yml`):** - jobs: `web`, `deploy-web` (opt-in via secrets), `linux`, `macos` (tekent + notariseert op `mac-brenno` met keychain-items), `windows-ophalen` (wacht tot 45 min op de GitHub-mirror-asset), `publiceren` (bundelt alles + `SHA256SUMS`), `website-downloads` (draait `scripts/bump-ocideck.sh <versie>` in de website-repo + `./publiceersite`). **Ná de tag, met de hand (lokaal, bewust off-runner):** - `make sign-release SHA256SUMS=…` → minisign detached signature over `SHA256SUMS` (privésleutel `~/.minisign/ocideck-release.key`, mét wachtwoord — mag nooit een runner-secret worden), `SHA256SUMS.minisig` aan de release hangen. - Eventueel `make deploy-web` als de deploy-secrets niet gezet zijn (nu het geval: gebruiker deployt zelf). **Relevante bouwstenen die al bestaan:** - `scripts/build_release.sh` (`make build-release`) — bouwt web + macOS lokaal, mét de adviserende catalogs-check ervóór. - `scripts/sign_release.sh` (`make sign-release`) — minisign. - `scripts/notarize_macos.sh` (`make notarize-macos`) — Developer-ID + notarisatie, lokaal. - `scripts/deploy_web.sh` (`make deploy-web`) — geharde webbundel live (verify → atomic swap → verify). - `make refresh-catalogs` — regenereert WSTG/MASTG/MASWE (bewust buiten `make check`). ## Voorgestelde opzet Eén commando met een **tag-argument**, dat drie fasen strikt volgtijdelijk draait en bij elke faalstap stopt (`set -Eeuo pipefail`-discipline). Voorstel voor de naam: `make release TAG=v0.2.1` (dun laagje over `scripts/release.sh`). ### Fase 1 — Lokaal voorbereiden (alles móét groen vóór de tag) 1. **Tag-guard.** Valideer `TAG` (semver, `v`-prefix) en controleer dat hij **strikt hoger** is dan de laatst uitgebrachte versie (`git tag --sort=-creatordate` / hoogste `v*`). Nooit gelijk of lager. Weiger anders, zonder iets te wijzigen. 2. **Updates laden en wegwerken vóór het bouwen.** Draai de verouderingschecks (`make catalogs-outdated`, `make deps-outdated`, `make check-pins`) en werk bij wat bijgewerkt moet worden (dit is de MASWE-aanleiding). Bij een gevonden hogere versie: `make refresh-catalogs` en de versies in `lib/services/reference_standards.dart` spiegelen, resp. de deps/pins bijwerken — conform de "hogere versie = overal bijwerken"-regel. *Ontwerpvraag:* volledig automatisch bijwerken, of stoppen-met-melding zodat de mens beslist? (catalogs is bewust adviserend gehouden; zie ontwerpvragen onderaan.) 3. **Versie doorzetten** op de vier plekken: `pubspec.yaml`, `kOciDeckVersion`, `CHANGELOG.md`-kop (unreleased → versie + datum), en `make sbom` opnieuw. 4. **Volledige poort groen:** `make check-release` (+ `make linux-gate`). Faalt er iets, dan stopt het proces hier — er wordt niets gepusht. 5. **Lokaal bouwen + tekenen** wat lokaal moet: `make build-release`, en op deze machine het **macOS-tekenen/notariseren** (`make notarize-macos`) — de release-signing gebeurt op deze machine. Verifieer het zegel (`codesign --verify --deep --strict`; let op de schone-build-valkuil: `flutter clean` vóór een build die je installeert). 6. **Systeemversie vervangen in de application-directory.** Kopieer de vers gebouwde, geverifieerde `.app` naar `/Applications` (eerst de draaiende app afsluiten; toets op `pgrep`, niet op de exitstatus van `osascript quit`). Alleen als het zegel groen is — een kapot zegel reist mee door `ditto`. ### Fase 2 — Naar de CI-straat en bewaken 7. **Tag zetten en pushen** naar `origin` (forge) én `mirror` (GitHub). Pas hier — geen tag zolang fase 1 niet volledig groen is. 8. **Remote bewaken, eens per minuut.** Poll de forge-run tot alle release-jobs klaar zijn (`web`, `linux`, `macos`, `windows-ophalen`, `publiceren`, eventueel `deploy-web` en `website-downloads`). Gebruik de REST-route die op deze instance wél werkt: `GET /releases?limit=N` + filter op `tag_name` voor de release, en de `actions/runs/{id}/jobs` → `jobs/{jobId}/logs`-route voor jobstatus/logs. *Let op de bekende valkuilen:* `GET /releases/tags/{tag}` is onbetrouwbaar op deze instance (gebruik de lijst), en een al-gepushte `v*`-tag mag je **nooit verplaatsen** (mislukte release → nieuwe patch-tag, niet hertaggen — anders degradeert de mirror-Windows-release tot draft en blijft `windows-ophalen` eeuwig wachten). ### Fase 3 — Verspreiden (pas ná groene CI) 9. **Manifest tekenen:** `SHA256SUMS` ophalen uit de gepubliceerde release, `make sign-release`, `SHA256SUMS.minisig` terughangen. 10. **Website van LibreKAT meenemen.** In principe doet de `website-downloads`-job dit al op de tag (`scripts/bump-ocideck.sh <versie>` + `./publiceersite`). De orkestrator moet dit **bewaken en, bij overslaan/falen, de handmatige terugval draaien** in de website-repo. *Zie ontwerpvraag over dubbeling met de bestaande job.* 11. **Web live** waar dat (nog) niet automatisch gaat: `make deploy-web` (zolang de deploy-secrets niet gezet zijn deployt de gebruiker zelf — dit punt respecteren, niet eigenmachtig overrulen). ## Detaileisen (expliciet gevraagd) - **Tag-argument** met **monotone guard**: de nieuwe versie mag **nooit lager of gelijk** zijn dan de vorige. Harde stop, geen wijzigingen, duidelijke melding. - **macOS release-signing op deze machine** (Developer-ID + notarisatie, keychain-items; privésleutels blijven lokaal, nooit als runner-secret). - **CI-bewaking eens per minuut**; verspreiding start **pas** als CI klaar is. - **LibreKAT-website** hoort bij de verspreiding. - **Lokaal de systeemversie in de application-directory vervangen** (`/Applications`). - Elke faalstap stopt de keten; niets half doen. Idempotent waar mogelijk (herstart na een gefaalde stap moet veilig zijn). ## Ontwerpvragen / aandachtspunten 1. **Verhouding tot de bestaande tag-gedreven pipeline.** Nu triggert de **tag** de hele CI-keten inclusief website-downloads en (opt-in) deploy-web. De gevraagde orkestrator zet lokaal-eerst en doet verspreiding "pas na CI". Er zit dus overlap: doet de orkestrator de website/deploy zélf, of **bewaakt** hij alleen de CI-jobs die dat al doen en springt hij alleen bij als die overslaan/falen? Voorkeur lijkt: **CI blijft de bron, orkestrator bewaakt + vult de handmatige gaten (minisign, /Applications, eventuele handmatige web-deploy)**. Vast te leggen vóór bouwen. 2. **Automatisch bijwerken vs. beslissen.** De catalogs-check is **bewust adviserend** (een nieuwe upstream-versie is een afweging, geen defect, en het bijwerken verandert waar een rapport naar verwijst). "Alles automatisch bumpen in het releaseproces" botst daarmee. Waarschijnlijk juiste vorm: de orkestrator **stopt met een duidelijke melding** als er iets bij te werken valt, doet het bijwerken als aparte, bevestigde stap, en gaat dan opnieuw door de poort — niet stilzwijgend meebumpen tijdens een release. 3. **Interactieve vertrouwenspunten.** Notarisatie-wachtwoord en minisign-wachtwoord zijn interactief. Het "één commando"-ideaal mag die niet omzeilen; het commando moet er netjes om vragen op het juiste moment (of duidelijk pauzeren). 4. **Waar leeft dit?** Eén `scripts/release.sh` met een dunne `make release TAG=…`-wrapper ligt voor de hand (consistent met `build_release.sh`/`sign_release.sh`). De CI-kant (`release.yml`) is grotendeels al af; de wens raakt vooral de **lokale orkestratie + bewaking**, niet zozeer nieuwe CI-jobs. Documenteren in `docs/BUILD.md`. 5. **Bewakingsroute robuust maken.** De REST-valkuilen (onbetrouwbare `/releases/tags/{tag}`, job-log-route) horen in het script afgevangen, niet elke keer opnieuw ontdekt. ## Acceptatiecriteria - [ ] Eén commando met tag-argument draait fase 1→2→3 volgtijdelijk en stopt bij de eerste fout. - [ ] Tag-guard weigert een versie die niet strikt hoger is dan de vorige, zonder wijzigingen. - [ ] Verouderingschecks (MASWE c.s.) worden aan het begin gedraaid en op de afgesproken manier afgehandeld (bijwerken of gecontroleerd stoppen). - [ ] Versie wordt op alle vier de plekken consistent doorgezet; `make check-release` groen vóór de tag. - [ ] macOS-tekenen/notariseren lokaal, met zegelverificatie; de nieuwe `.app` vervangt de versie in `/Applications`. - [ ] Tag naar forge + mirror; CI wordt eens per minuut bewaakt tot klaar. - [ ] Verspreiding pas ná groene CI: minisign-manifest, LibreKAT-website bijgewerkt en live, web live (of expliciet aan de gebruiker gelaten zolang dat de afspraak is). - [ ] Werkwijze en valkuilen gedocumenteerd in `docs/BUILD.md`; een `tool/`-poort of test dekt de tag-guard (een bugfix/gedragsregel krijgt een toets). ## Raakvlakken (bestanden) `scripts/build_release.sh`, `scripts/sign_release.sh`, `scripts/notarize_macos.sh`, `scripts/deploy_web.sh`, `Makefile` (release-targets), `.forgejo/workflows/release.yml`, `pubspec.yaml`, `lib/services/export_metadata.dart`, `CHANGELOG.md`, `sbom/`, `lib/services/reference_standards.dart` (+ `make refresh-catalogs`), de website-repo (`scripts/bump-ocideck.sh`, `./publiceersite`), `docs/BUILD.md`.

brenno added the

enhancement

in-progress

labels

2026-08-03 12:28:13 +00:00

brenno commented

2026-08-04 08:51:45 +00:00

Author

Owner

Opgepakt. Tak: feat/1161-release-orchestrator. Ik begin met de veilige, testbare kern uit de acceptatiecriteria: scripts/release.sh met de monotone tag-guard (semver + v-prefix, strikt hoger dan de vorige release-tag, harde stop zonder wijzigingen) en de gefaseerde skelet-structuur (fase 1 lokaal → 2 CI-bewaking → 3 verspreiding), plus een tool-poort die de tag-guard toetst. De live-CI-polling en distributie bouw ik gefaseerd erop; de interactieve vertrouwenspunten (notarisatie/minisign) blijven expliciet.

brenno referenced this issue

2026-08-04 08:58:56 +00:00

feat(release): make release TAG=… — monotone tag-guard + Phase 1 (#1161) #1205

brenno referenced this issue from a commit

2026-08-04 08:58:58 +00:00

feat(release): make release TAG=… — monotone tag-guard + Phase 1 (#1161)

brenno referenced this issue from a commit

2026-08-04 09:07:37 +00:00

feat(release): make release TAG=… — monotone tag-guard + Phase 1 (#1161)

brenno referenced this issue from a commit

2026-08-04 09:47:56 +00:00

feat(release): make release TAG=… — monotone tag-guard + Phase 1 (#1161)

brenno referenced this issue from a commit

2026-08-04 09:52:23 +00:00

feat(release): make release TAG=… — monotone tag-guard + Phase 1 (#1161)

brenno commented

2026-08-04 09:52:39 +00:00

Author

Owner

Eerste iteratie gemerged op main (PR #1205): make release TAG=vX.Y.Z (scripts/release.sh) met de monotone tag-guard (vX.Y.Z zonder suffix, == v+pubspec-versie, nog niet bestaand, geldige één-as-bump via de al geteste make check-version-bump) + fase 1 (catalogs-outdated, check-release, build-release, notarize-macos). Guard geverifieerd tegen vijf foutgevallen, shellcheck schoon, docs/BUILD.md bij. Blijft OPEN: de onomkeerbare fase 2-3 (tag→mirror-push, CI-bewaking per minuut, minisign-manifest, LibreKAT-website, /Applications-vervanging) wordt bewust nog niet automatisch afgevuurd — het script drukt die als geordende vervolgstappen af. Die automatisering is de volgende iteratie, ná het bewijzen van de orkestrator.

Eerste iteratie gemerged op main (PR #1205): `make release TAG=vX.Y.Z` (scripts/release.sh) met de monotone tag-guard (vX.Y.Z zonder suffix, == v+pubspec-versie, nog niet bestaand, geldige één-as-bump via de al geteste make check-version-bump) + fase 1 (catalogs-outdated, check-release, build-release, notarize-macos). Guard geverifieerd tegen vijf foutgevallen, shellcheck schoon, docs/BUILD.md bij. Blijft OPEN: de onomkeerbare fase 2-3 (tag→mirror-push, CI-bewaking per minuut, minisign-manifest, LibreKAT-website, /Applications-vervanging) wordt bewust nog niet automatisch afgevuurd — het script drukt die als geordende vervolgstappen af. Die automatisering is de volgende iteratie, ná het bewijzen van de orkestrator.

brenno removed the

in-progress

label

2026-08-04 09:53:12 +00:00

brenno referenced this issue from a commit

2026-08-04 20:58:29 +00:00

feat(release): onbewaakt release-script met één wachtwoord (#1161)

brenno referenced this issue from a pull request that will close it,

2026-08-04 21:00:03 +00:00

feat(release): onbewaakt release-script met één wachtwoord (#1161) #1239

brenno commented

2026-08-04 21:00:22 +00:00

Author

Owner

Iteratie 2 (de onbewaakte automatisering van fase 2-3) staat klaar op tak feat/release-auto → PR #1239. Menu voor het SemVer-niveau + één minisign-wachtwoord vooraan, daarna onbewaakt t/m tag-push, tekenen en deploy-web; verouderingsgate, ERR-trap-fail-safe, --dry-run/--print-version en test/release_auto_version_test.dart voor de guard. Sluit dit issue bij merge.

Iteratie 2 (de onbewaakte automatisering van fase 2-3) staat klaar op tak `feat/release-auto` → PR #1239. Menu voor het SemVer-niveau + één minisign-wachtwoord vooraan, daarna onbewaakt t/m tag-push, tekenen en deploy-web; verouderingsgate, ERR-trap-fail-safe, `--dry-run`/`--print-version` en `test/release_auto_version_test.dart` voor de guard. Sluit dit issue bij merge.

brenno referenced this issue from a commit

2026-08-04 21:06:21 +00:00

feat(release): onbewaakt release-script met één wachtwoord (#1161)

brenno closed this issue

2026-08-04 21:12:08 +00:00

brenno referenced this issue from a commit

2026-08-04 21:12:09 +00:00

Merge pull request 'feat(release): onbewaakt release-script met één wachtwoord (#1161)' (#1239) from feat/release-auto into main

brenno referenced this issue from a commit

2026-08-04 22:04:42 +00:00

ci(release): make bump-scanner-pins + automatische scanner-bump (#1161)

brenno referenced this issue