Restverspilling in de bouwstraat na het weghalen van de wachtende machine

[ericwout-overheid]

Aanleiding

Bij MinBZK/moza-poc-fbs-berichtenbox#173 is de grootste verspilling in de bouwstraat weggenomen: een machine die per wijziging
bijna acht minuten stond te wachten. Tijdens die analyse kwamen vier kleinere posten boven water
die nog blijven staan. Elk is klein genoeg om níét met MinBZK/moza-poc-fbs-berichtenbox#173 mee te nemen, en samen groot genoeg om
niet te vergeten.

Effect

Machinetijd en cluster-capaciteit die geen resultaat opleveren. Geen van deze posten raakt de
werking van de dienst; het gaat om verbruik zonder functie.

Wat er nog blijft staan

1. Dezelfde vraag vier keer stellen. Vier processen bepalen elk apart of een wijziging alleen
   documentatie raakt. Samen ~211 korte machinestarts per week.
2. Bouwen voor een uitrol die niet komt. Opgelost in fix(ci): preview rolt uit per commit via unieke image-tag moza-poc-fbs-berichtenbox#172 — het bouwen hangt daar nu
   aan dezelfde beslissing als het uitrollen, en slaat behalve documentatie-wijzigingen ook
   bot-voorstellen over.
3. Een pakket herbouwen dat niet veranderd is. Het testhulpje voor externe koppelingen wordt
   bij elke wijziging opnieuw gebouwd en gepubliceerd, ook als er niets aan veranderd is.
4. Een voorvertoning uitrollen die identiek is aan de vorige. Wijzigingen die de applicatie
   niet raken (bouwstraat-configuratie, voorbeeldverzoeken) rollen toch drie voorvertoningen uit.
   Dit is de enige post die echte serverruimte kost in plaats van alleen machinetijd.
5. Een achtergebleven pakket bij snel sluiten. Sluit iemand een voorstel binnen ~85 seconden na
   een wijziging, dan kan het opruimen klaar zijn vóórdat de laatste bouw zijn pakket publiceert.
   Dat pakket blijft dan staan. Geen storing, wel een langzaam groeiende berg.

Acceptatiecriteria

Per post geldt: óf het verbruik verdwijnt, óf er ligt een vastgelegde afweging waarom het blijft.
Voorwaarde bij elke oplossing: een wijziging mag nooit stilzwijgend ongetoetst of onuitgerold
blijven — een controle die "overgeslagen" rapporteert telt door als geslaagd, dus een fout in de
overslag-logica is direct een gat in de kwaliteitsbewaking.

---

Technische context

1. Vier changes-jobs met dezelfde detectie

deploy.yml, test.yml, detekt.yml en cflite_pr.yml hebben elk een changes-job. De eerste
drie draaien exact dezelfde grep -qvE '(^docs/|\.md$)'-detectie; cflite_pr.yml heeft een eigen
fuzz-relevantiefilter. Gemeten 3–10 augustus 2026: 62 + 53 + 53 + 43 = 211 jobs, ~841 s billed —
maar de echte kost is 211 runner-allocaties, niet de 14 minuten die ervan geteld worden.

Dedupliceren kan sinds MinBZK/moza-poc-fbs-berichtenbox#173 via een workflow_call-input, want deploy.yml roept de andere aan.
Valkuil die bij het uitwerken bovenkwam: laat je checks-test van changes afhangen, dan wordt
bij een falende changes-job de testjob overgeslagen — en skipped telt door als succes voor
branch protection, dus ongeteste code wordt merge-baar. Sluitbaar met !cancelled() op de
caller-job plus "sla alleen over bij een expliciete false" in plaats van "draai alleen bij
true", zodat elke onverwachte toestand fail-safe naar wel draaien valt.

2. build hangt niet aan changes — OPGELOST in MinBZK/moza-poc-fbs-berichtenbox#172

build en build-externe-stubs hebben daar nu needs: [meta, changes] plus
needs.changes.outputs.run == 'true', en changes sluit behalve docs-only ook bot-PR's uit. De
blokkade die hier genoemd stond — de cleanup die een niet-bestaande exacte tag zou verwijderen —
verviel in dezelfde wijziging, doordat cleanup-preview-images op prefix pr-<n>- werkt.

3. build-externe-stubs zonder paths-filter

docker build + docker push van wiremock/externe-stubs bij elke commit: 52 runs, ~1.125 s in
de meetweek, plus 52 image-pushes. De inhoud wijzigt zelden. Een paths-filter is niet triviaal,
want de deploy-jobs verwachten een image op de tag van déze run; overslaan vergt een
tag-hergebruikstrategie die botst met de per-commit-tag uit MinBZK/moza-poc-fbs-berichtenbox#171/#172.

4. Preview-uitrol voor niet-applicatieve wijzigingen

Het changes-filter kijkt alleen naar docs/ en *.md. Een PR die uitsluitend
.github/workflows/, bruno/ of demo/ raakt, rolt drie ZAD-previews uit met een image die
functioneel gelijk is aan de vorige. Dat is de enige post met echt clusterverbruik
(pods, volumes, ingress) in plaats van alleen runnertijd — en daarmee waarschijnlijk de grootste
energiepost van de vier.

Tegenargument: een wijziging in .github/workflows/ kán de deploy zelf raken, en dan is een
preview juist wél zinvol. Een filter moet dat onderscheid maken, of de uitzondering expliciet
benoemen.

5. Race tussen cleanup-preview-images en een lopende build

Vóór MinBZK/moza-poc-fbs-berichtenbox#174 hield een workflow-brede concurrency met cancel-in-progress: false de runs van één
PR op volgorde: een close-run wachtte op een lopende build. MinBZK/moza-poc-fbs-berichtenbox#174 verplaatste die concurrency naar
job-niveau (nodig, anders zou een opvolgende push wachten op de vorige deploy én de achterhaalde
testrun helemaal uitdraaien). Gevolg: bij een close binnen ~85 s na een push kan
cleanup-preview-images de sweep afronden vóórdat de build zijn pr-<n>-<sha7>-tag pusht, en
blijft die versie staan.

De build-jobs kunnen niet in de cleanup-groep meedraaien: ze hebben er per service al één, anders
blokkeren de drie parallelle builds elkaar. Een job kan maar in één groep zitten.

Denkrichting: cleanup-preview-images als matrix over de drie packages, elke instantie in de
concurrency-groep van de bijbehorende build-job met cancel-in-progress: true — dan breekt het
opruimen de lopende build af vóór het sweept. Kost drie korte jobs per close in plaats van één
(~9 closes per week). Nog niet uitgewerkt of het de complexiteit waard is tegenover één weesversie
in een zeldzaam geval.

Staat als bekende beperking in de kop van cleanup-preview-images in deploy.yml.

Meting

Reproduceerbaar met de scripts uit de beschrijving van MinBZK/moza-poc-fbs-berichtenbox#174.

[ericwout-overheid]

Bijgewerkt na de merge van MinBZK/moza-poc-fbs-berichtenbox#172 in MinBZK/moza-poc-fbs-berichtenbox#174: post 2 (bouwen voor een uitrol die niet komt) is opgelost door MinBZK/moza-poc-fbs-berichtenbox#172 zelf. Post 5 toegevoegd — het verplaatsen van de concurrency naar job-niveau in MinBZK/moza-poc-fbs-berichtenbox#174 laat een klein venster open waarin cleanup-preview-images een nog lopende build kan mislopen.

[ericwout-overheid]

Draft-PR staat klaar: MinBZK/moza-poc-fbs-berichtenbox#191 (gestapeld op MinBZK/moza-poc-fbs-berichtenbox#190).

Post 1 en 4 zijn opgelost, 3 en 5 hebben een vastgelegde afweging gekregen — conform het acceptatiecriterium.

Post 1: één detectie in deploy.yml met vier uitkomsten, doorgegeven als input. De valkuil die je beschreef is dichtgezet met !cancelled() plus "sla alleen over bij een expliciete false", zodat elke onverwachte toestand fail-safe naar wél draaien valt. Zijeffect: de code-checks draaien nu ook op bot-PR's; die worden alleen niet uitgerold.

Post 4: de deploy-poort is strenger dan de check-poort geworden. bruno/ en demo/ zitten in geen enkel image, dus die rollen geen preview meer uit. .github/ heb ik er bewust buiten gelaten — precies om het tegenargument dat je noemt.

De echte toets is de CI-run van deze PR: die laat zien of de check-runs onder dezelfde namen verschijnen. De job-ids zijn ongewijzigd gebleven, juist omdat branch protection daarop pint.

[ericwout-overheid]

Statusupdate

Bijbehorende PR	MinBZK/moza-poc-fbs-berichtenbox#191 — chore(ci): stel de wijzigingsvraag nog één keer in plaats van vier keer (open, draft; gestapeld op #190)
Milestone	Sprint 8 - Lovelace
Status	🏃 In uitvoering

Aanleiding lag in MinBZK/moza-poc-fbs-berichtenbox#174 (gemerged), waar de wachtende bouwmachine verdween.