De Windows-installer rijdt mee in de releaseketen #1587

Merged

brenno merged 1 commit from feat/installer-in-release into main

2026-08-19 18:25:05 +00:00

brenno commented

2026-08-19 18:18:17 +00:00

Owner

Sluit #1583. De installer uit #1208 bestond wel, maar kwam bij geen enkele release terecht.

De aanname die niet klopte

"Er is geen Windows-runner" gold voor de forge, niet voor de keten: .github/workflows/release.yml op de spiegel bouwt bij elke v*-tag al de Windows-zip die de forge met curl terughaalt. De installer kan daar gewoon uit komen.

Spiegel

Inno Setup zelf ophalen. Niet via Chocolatey — dat zou een extra partij in het releasepad zetten voor een bestand dat upstream gewoon als GitHub release-asset publiceert. Dubbel gepind: op versie (INNOSETUP_VERSION, ook in .github/pinned-ci-versions.json, anders valt pinned_versions_manifest_test) én op sha256, zodat vervangen bytes luid falen in plaats van stil iets anders te bouwen. Dat is nodig omdat windows-latest Inno Setup niet meer meelevert sinds dat label naar Server 2025 wees.

Installer vóór de zip. Het script tekent ocideck.exe en de dll's ter plekke zodra OCIDECK_WIN_SIGN_SHA1 gezet is. Zip je eerst, dan draagt de zip ongetekende binaries en de installer getekende — twee downloads die niet dezelfde bouw zijn. De poort houdt die volgorde vast.

Versie uit de tag, niet uit pubspec. De forge haalt op onder een naam die uit de tag is afgeleid. Zou het script hier zelf pubspec.yaml lezen, dan levert een tag die even vooruitloopt een bestand op dat de forge niet kan vinden — een release die vastloopt op een naamsverschil.

Forge

windows-ophalen haalt beide bestanden op en weigert klaar te zijn met maar één. Zonder dat verlaat een halve spiegel-run (of een oude release waar alleen de zip aan hangt) deze job groen, en publiceert de forge een release waarin stilzwijgend één bestand ontbreekt. Ze landen vóór de Checksums-stap, dus de installer staat in SHA256SUMS en valt onder de minisign-handtekening.

Dat is precies de voorwaarde die de bewakerstoets bij #1208 stelde — een ongetekende installer die om verhoging vraagt heeft anders geen enkele herkomst — nu niet meer als belofte in de documentatie maar afgedwongen door de keten.

De pin-monitor

Inno Setup tagt is-7_1_0, niet 7.1.0. check_pinned_versions kende die vorm niet en zou de pin élke run als verouderd melden; een monitor die altijd afgaat leest niemand. Vandaar een optionele tag_regex in het manifest.

Gepind op 7.1.0, niet op de 6-lijn: 7 houdt uitdrukkelijk achterwaartse compatibiliteit, en de gedocumenteerde breekpunten zitten allemaal in Pascal Script en preprocessor-functies — waar dit .iss er geen van heeft, want een [Code]-sectie is door de poort verboden. Het pad naar ISCC.exe staat niet meer in de workflow: 6 en 7 staan naast elkaar en de 64-bit-editie landt onder een andere Program Files-root, dus het script zoekt het zelf.

De rest van de keten nagelopen

release_auto.sh en sign_release.sh blijken artefact-agnostisch — die controleren alleen dat SHA256SUMS + handtekening bestaan. De installer komt vanzelf in het manifest via sha256sum ./*. release_package_layout_test.dart en homebrew_cask_test.dart raken hem niet. Geen wijziging nodig, wel gecontroleerd in plaats van aangenomen.

Toetsen

make check groen (9.938 tests, dekking 87,1%, per-bestand-vloer 0); make check-static en make check-registrations apart groen.
Acht nieuwe controles over de hele keten: pin aanwezig + geverifieerd, manifest en workflow eens over de versie, bouwvolgorde, versie uit de tag, één bestandsnaam aan beide kanten, have_asset eist beide, de artifact-glob versmalt niet, en de releasetekst biedt hem aan mét de "werkt zichzelf niet bij"-zin.
Mutatiegetoetst: zes van de zes betrapt. De eerste ronde miste er één, en dat legde een echte zwakte bloot — mijn assertie eiste de bestandsnaam érgens in de releasetekst in plaats van in de downloadtabel, en dat is de regel die een lezer daadwerkelijk gebruikt. Aangescherpt tot een tabelrij.
make check-secrets en make sast groen (zie #1582, ongewijzigd sindsdien voor deze bestanden).

Documentatie

docs/BUILD.md, packaging/README.md, docs/KNOWN_LIMITATIONS.md, docs/FAQ.md, .forgejo/release-body.md en de changelog. Een deel daarvan is een correctie op mijn eigen tekst van gisteren, die nog beweerde dat de installer handwerk is en niet uit de release komt.

Website

Aparte PR in LibreKAT/website (tak feat/ocideck-windows-installer): het installerblok verschijnt daar automatisch zodra een release hem draagt. Die PR bevat ook een bugfix die hier los van staat — de site toonde een verkeerde Windows-checksum.

Sluit #1583. De installer uit #1208 bestond wel, maar kwam bij geen enkele release terecht. ## De aanname die niet klopte "Er is geen Windows-runner" gold voor de forge, niet voor de keten: `.github/workflows/release.yml` op de spiegel bouwt bij elke `v*`-tag al de Windows-zip die de forge met `curl` terughaalt. De installer kan daar gewoon uit komen. ## Spiegel **Inno Setup zelf ophalen.** Niet via Chocolatey — dat zou een extra partij in het releasepad zetten voor een bestand dat upstream gewoon als GitHub release-asset publiceert. Dubbel gepind: op versie (`INNOSETUP_VERSION`, ook in `.github/pinned-ci-versions.json`, anders valt `pinned_versions_manifest_test`) én op sha256, zodat vervangen bytes luid falen in plaats van stil iets anders te bouwen. Dat is nodig omdat `windows-latest` Inno Setup niet meer meelevert sinds dat label naar Server 2025 wees. **Installer vóór de zip.** Het script tekent `ocideck.exe` en de dll's ter plekke zodra `OCIDECK_WIN_SIGN_SHA1` gezet is. Zip je eerst, dan draagt de zip ongetekende binaries en de installer getekende — twee downloads die niet dezelfde bouw zijn. De poort houdt die volgorde vast. **Versie uit de tag, niet uit pubspec.** De forge haalt op onder een naam die uit de tag is afgeleid. Zou het script hier zelf `pubspec.yaml` lezen, dan levert een tag die even vooruitloopt een bestand op dat de forge niet kan vinden — een release die vastloopt op een naamsverschil. ## Forge `windows-ophalen` haalt **beide** bestanden op en weigert klaar te zijn met maar één. Zonder dat verlaat een halve spiegel-run (of een oude release waar alleen de zip aan hangt) deze job groen, en publiceert de forge een release waarin stilzwijgend één bestand ontbreekt. Ze landen vóór de `Checksums`-stap, dus de installer staat in `SHA256SUMS` en valt onder de minisign-handtekening. Dat is precies de voorwaarde die de bewakerstoets bij #1208 stelde — een ongetekende installer die om verhoging vraagt heeft anders geen enkele herkomst — nu niet meer als belofte in de documentatie maar afgedwongen door de keten. ## De pin-monitor Inno Setup tagt `is-7_1_0`, niet `7.1.0`. `check_pinned_versions` kende die vorm niet en zou de pin élke run als verouderd melden; een monitor die altijd afgaat leest niemand. Vandaar een optionele `tag_regex` in het manifest. Gepind op **7.1.0**, niet op de 6-lijn: 7 houdt uitdrukkelijk achterwaartse compatibiliteit, en de gedocumenteerde breekpunten zitten allemaal in Pascal Script en preprocessor-functies — waar dit `.iss` er geen van heeft, want een `[Code]`-sectie is door de poort verboden. Het pad naar `ISCC.exe` staat niet meer in de workflow: 6 en 7 staan naast elkaar en de 64-bit-editie landt onder een andere Program Files-root, dus het script zoekt het zelf. ## De rest van de keten nagelopen `release_auto.sh` en `sign_release.sh` blijken artefact-agnostisch — die controleren alleen dat `SHA256SUMS` + handtekening bestaan. De installer komt vanzelf in het manifest via `sha256sum ./*`. `release_package_layout_test.dart` en `homebrew_cask_test.dart` raken hem niet. Geen wijziging nodig, wel gecontroleerd in plaats van aangenomen. ## Toetsen - `make check` groen (9.938 tests, dekking 87,1%, per-bestand-vloer 0); `make check-static` en `make check-registrations` apart groen. - **Acht nieuwe controles** over de hele keten: pin aanwezig + geverifieerd, manifest en workflow eens over de versie, bouwvolgorde, versie uit de tag, één bestandsnaam aan beide kanten, `have_asset` eist beide, de artifact-glob versmalt niet, en de releasetekst biedt hem aan mét de "werkt zichzelf niet bij"-zin. - **Mutatiegetoetst: zes van de zes betrapt.** De eerste ronde miste er één, en dat legde een echte zwakte bloot — mijn assertie eiste de bestandsnaam *érgens* in de releasetekst in plaats van in de downloadtabel, en dat is de regel die een lezer daadwerkelijk gebruikt. Aangescherpt tot een tabelrij. - `make check-secrets` en `make sast` groen (zie #1582, ongewijzigd sindsdien voor deze bestanden). ## Documentatie `docs/BUILD.md`, `packaging/README.md`, `docs/KNOWN_LIMITATIONS.md`, `docs/FAQ.md`, `.forgejo/release-body.md` en de changelog. Een deel daarvan is een **correctie op mijn eigen tekst van gisteren**, die nog beweerde dat de installer handwerk is en niet uit de release komt. ## Website Aparte PR in `LibreKAT/website` (tak `feat/ocideck-windows-installer`): het installerblok verschijnt daar automatisch zodra een release hem draagt. Die PR bevat ook een bugfix die hier los van staat — de site toonde een **verkeerde** Windows-checksum.

brenno added 1 commit

2026-08-19 18:18:17 +00:00

feat(release): de Windows-installer rijdt mee in de releaseketen

scans / scans (pull_request) Successful in 2m42s

Details

static-gate / static-gate (pull_request) Successful in 6m17s

Details

626e9f0d83

Sluit #1583. De installer bestond wel, maar kwam bij geen enkele release
terecht — hij moest met de hand op een Windows-machine gemaakt worden. Dat
hoefde niet: de forge heeft geen Windows-machine, maar de spiegel op github.com
bouwt daar bij elke v*-tag al de Windows-zip die de forge terughaalt.

**Spiegel.** De job haalt Inno Setup zelf op — rechtstreeks bij de uitgever en
niet via Chocolatey, dat zou een extra partij in het releasepad zetten voor een
bestand dat upstream gewoon als release-asset publiceert. Dubbel gepind: op
versie (ook in .github/pinned-ci-versions.json, anders valt de
manifesttest) en op sha256, zodat vervangen bytes lúid falen. Daarna bouwt hij
de installer en hangt beide bestanden aan de spiegel-release.

De installer wordt vóór het zippen gebouwd. Het script tekent de exe en de
dll's ter plekke zodra er een certificaat is ingesteld; zip je eerst, dan draagt
de zip ongetekende binaries en de installer getekende — twee downloads die niet
dezelfde bouw zijn. De poort houdt die volgorde vast.

De versie komt uit de tag en niet uit pubspec.yaml. De forge haalt op onder een
naam die uit de tag is afgeleid; zou het script hier zelf pubspec lezen, dan
levert een tag die even vooruitloopt een bestand op dat de forge niet kan
vinden.

**Forge.** `windows-ophalen` haalt beide bestanden op en weigert klaar te zijn
met maar één. Zonder dat zou een halve spiegel-run deze job groen verlaten en
publiceert de forge een release waarin stilzwijgend één bestand ontbreekt. Ze
komen binnen vóór de Checksums-stap, dus de installer staat in SHA256SUMS en
valt daarmee onder de minisign-handtekening — precies de voorwaarde die in de
bewakerstoets van #1208 is vastgelegd, nu ook echt afgedwongen.

**Pin-monitor.** Inno Setup tagt zijn releases `is-7_1_0`, niet `7.1.0`.
check_pinned_versions kende die vorm niet en zou de pin élke run als verouderd
melden; een monitor die altijd afgaat leest niemand. Vandaar een optionele
`tag_regex` in het manifest. Gepind op 7.1.0 en niet op de 6-lijn: 7 houdt
uitdrukkelijk achterwaartse compatibiliteit, en de gedocumenteerde breekpunten
zitten allemaal in Pascal Script en preprocessor-functies — waar dit .iss-script
er geen van heeft, want een [Code]-sectie is verboden door de poort.

Acht nieuwe controles over de hele keten, mutatiegetoetst (zes van de zes
betrapt). Eén daarvan legde een zwakte in mijn eigen assertie bloot: die eiste
de bestandsnaam érgens in de releasetekst in plaats van in de downloadtabel,
en dat is de regel die een lezer gebruikt.

Ook rechtgezet: de documentatie van gisteren beweerde nog dat de installer
handwerk is en niet uit de release komt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

brenno merged commit 6fca5b0352 into main

2026-08-19 18:25:05 +00:00

brenno referenced this pull request from a commit

2026-08-19 18:25:05 +00:00

De Windows-installer rijdt mee in de releaseketen (#1587)

brenno referenced this pull request

2026-08-19 18:26:11 +00:00

Windows-installer meenemen in de bouwlijn op de spiegel — of bewust handwerk laten #1583