ci: de poort draait op een tag, niet op elke PR #790

Merged

brenno merged 2 commits from ci/cache-toolchain-en-pub into main

2026-07-24 10:16:57 +00:00

brenno commented

2026-07-24 09:27:04 +00:00

Owner

De poort duurde 22 minuten op de eigen runner tegen 2,5 minuut lokaal. Dat werkt niet in de praktijk, dus hij draait nu op een v*-tag in plaats van op elke PR.

Wat dit echt betekent

Dit is geen versnelling maar een verschuiving, en die staat er hardop bij in de workflow zelf én in CONTRIBUTING, BUILD, CHECKS en de README:

CI is hiermee geen samenvoegpoort meer maar een uitbrengpoort. Valt hij op een tag om, dan staat het probleem al op main. De borging vóór main is vanaf nu volledig make check op de machine van de committer.

Die vier documenten beloofden tot nu toe letterlijk "on every pull request". Een belofte die niet meer waar is, is erger dan geen belofte, dus die zijn alle vier bijgewerkt — inclusief de zin in CONTRIBUTING die al scheef stond ("no CI runner, so nothing runs it for you").

workflow_dispatch blijft erop, zodat een tak alsnog door de poort kan zonder dat je een tag hoeft te zetten.

Verder in deze tak

Toolchain en pub-pakketten gecachet. Elke run haalde dezelfde Flutter-tarball opnieuw op, sha256-controleerde hem en pakte hem uit met xz — werk dat per definitie hetzelfde antwoord geeft. Er is geen controle ingeleverd: check-toolchain draait binnen make check op de herstelde boom en eist onverkort kanaal stable, de officiële herkomst en gelijkheid met de pin. De cache vervangt een download, geen controle. Beide cachestappen staan op continue-on-error.
Desktopbuilds alleen op afroep. Die draaiden bij elke push naar main (17,5 min voor Linux), terwijl release.yml op de GitHub-spiegel bij elke tag al drie platforms bouwt.

Eén correctie op de aanleiding

Op een PR draaide al géén enkele desktopbuild. Die 22 minuten waren voor honderd procent de poort — het wegzetten van de builds scheelt dus wachttijd na de merge, niet ervoor.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

Generated with Claude Code

De poort duurde 22 minuten op de eigen runner tegen 2,5 minuut lokaal. Dat werkt niet in de praktijk, dus hij draait nu op een `v*`-tag in plaats van op elke PR. ## Wat dit echt betekent Dit is geen versnelling maar een verschuiving, en die staat er hardop bij in de workflow zelf én in CONTRIBUTING, BUILD, CHECKS en de README: **CI is hiermee geen samenvoegpoort meer maar een uitbrengpoort.** Valt hij op een tag om, dan staat het probleem al op `main`. De borging vóór `main` is vanaf nu volledig `make check` op de machine van de committer. Die vier documenten beloofden tot nu toe letterlijk "on every pull request". Een belofte die niet meer waar is, is erger dan geen belofte, dus die zijn alle vier bijgewerkt — inclusief de zin in CONTRIBUTING die al scheef stond ("no CI runner, so nothing runs it for you"). `workflow_dispatch` blijft erop, zodat een tak alsnog door de poort kan zonder dat je een tag hoeft te zetten. ## Verder in deze tak - **Toolchain en pub-pakketten gecachet.** Elke run haalde dezelfde Flutter-tarball opnieuw op, sha256-controleerde hem en pakte hem uit met `xz` — werk dat per definitie hetzelfde antwoord geeft. Er is geen controle ingeleverd: `check-toolchain` draait binnen `make check` op de herstelde boom en eist onverkort kanaal `stable`, de officiële herkomst en gelijkheid met de pin. De cache vervangt een download, geen controle. Beide cachestappen staan op `continue-on-error`. - **Desktopbuilds alleen op afroep.** Die draaiden bij elke push naar main (17,5 min voor Linux), terwijl `release.yml` op de GitHub-spiegel bij elke tag al drie platforms bouwt. ## Eén correctie op de aanleiding Op een **PR** draaide al géén enkele desktopbuild. Die 22 minuten waren voor honderd procent de poort — het wegzetten van de builds scheelt dus wachttijd na de merge, niet ervoor. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Generated with [Claude Code](https://claude.com/claude-code)

brenno added 1 commit

2026-07-24 09:27:04 +00:00

ci: cache de gepinde toolchain en de pub-pakketten, bouw alleen op afroep

ci / gate (pull_request) Failing after 46m15s

Details

e2707863ff

Een poortrun duurde 22 minuten. Nagemeten waar die tijd heen ging, en de
aanname bleek te kloppen noch de voor de hand liggende oplossing:

- Op een **PR** draaide al geen enkele build — alleen `ci.yml`. Die 22 minuten
  zijn dus voor honderd procent de poort; "bouwen alleen bij een tag" zou nul
  seconden wachttijd hebben gescheeld.
- Dezelfde `make check` doet er lokaal 2,5 minuut over. De macOS-build op de
  Mac-runner duurt 1,5 minuut, de Linux-build in de pawprint-container 17,5.
  Diezelfde factor tien zit in de poort: het is de runner, niet het werk.

Wat er nu wél weg is: elke run haalde de Flutter-tarball opnieuw op,
sha256-controleerde hem en pakte hem uit met `xz` — werk dat per definitie
hetzelfde resultaat geeft, want de sleutel is de gepinde versie. Gecachet, net
als de pub-pakketten (op `pubspec.lock`, met terugvalsleutel zodat pub bij een
gewijzigde afhankelijkheid alleen het verschil ophaalt).

Er is geen controle ingeleverd. `check-toolchain` draait binnen `make check`
op de herstelde boom en eist onverkort kanaal `stable`, de officiële herkomst
en gelijkheid met de pin — dezelfde poort die het cirruslabs-image afkeurde.
De cache wordt geschreven door onze eigen jobs op onze eigen runner: wie de
runner beheert beheert de cache, en dat is dezelfde vertrouwensgrens als de
runner zelf. Beide cachestappen staan op `continue-on-error`, dus spreekt de
forge deze cache-API niet, dan verliezen we de versnelling en verder niets.

Daarnaast opgeruimd: de forge-builds draaiden bij elke push naar main en
kostten daar 17,5 minuten, terwijl `release.yml` op de GitHub-spiegel bij elke
`v*`-tag al drie platforms bouwt. Nu `workflow_dispatch` — niet weggegooid,
want een bundel op afroep zonder tag is wel wat waard.

BUILD/CHECKS/README droegen de oude belofte ("on every push to main") en zijn
bijgewerkt.

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

brenno changed title from ~~ci: cache de gepinde toolchain en de pub-pakketten, bouw alleen op afroep~~ to ci: de poort draait op een tag, niet op elke PR

2026-07-24 10:15:01 +00:00

brenno added 1 commit

2026-07-24 10:15:02 +00:00

ci: de poort draait op een tag, niet op elke PR e40e0a11b6

Een poortrun kostte 22 minuten op de eigen runner tegen 2,5 minuut lokaal. Die
wachttijd per PR woog niet op tegen wat hij toevoegde: `make check` is dezelfde
poort en draait al vóór elke push.

De verschuiving die daarbij hoort staat er hardop bij, in de workflow én in
CONTRIBUTING, BUILD, CHECKS en de README: **CI is hiermee geen samenvoegpoort
meer maar een uitbrengpoort.** Valt hij op een tag om, dan staat het probleem al
op main, en de borging vóór main is volledig `make check` op de machine van de
committer. Die vier documenten beloofden tot nu toe letterlijk "on every pull
request"; een belofte die niet meer waar is, is erger dan geen belofte.
`workflow_dispatch` blijft, zodat een tak alsnog door de poort kan zonder tag.

Verder in deze tak, en ongewijzigd: de gepinde toolchain en de pub-pakketten
worden gecachet (zonder een controle in te leveren — `check-toolchain` draait
binnen `make check` op de herstelde boom), en de desktopbuilds draaien alleen
nog op afroep in plaats van bij elke push naar main.

Voor de goede orde, want de aanname lag eerst anders: op een PR draaide al géén
enkele desktopbuild. Die 22 minuten waren voor honderd procent de poort.

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

brenno merged commit 3fe2f52b02 into main

2026-07-24 10:16:57 +00:00

brenno referenced this pull request from a commit

2026-07-24 10:16:59 +00:00

Merge pull request 'ci: de poort draait op een tag, niet op elke PR' (#790) from ci/cache-toolchain-en-pub into main

brenno referenced this pull request

2026-07-24 13:25:08 +00:00

perf(poort): de tagpoort meet geen dekking meer, en de runner draait één taak tegelijk #796

brenno referenced this pull request

2026-07-24 13:41:33 +00:00

perf(poort): de uitbrengpoort draait op de Mac-runner — 46 min naar 2 min 51 #797

brenno referenced this pull request from a commit