fix(scans): de poort wordt niet meer rood om iets wat geen vondst is #805

Merged

brenno merged 3 commits from fix/scans-concurrency into main

2026-07-24 16:55:09 +00:00

brenno commented

2026-07-24 16:15:26 +00:00

Owner

Nazorg bij #778 / PR #799. De aanleiding is gemeten, niet vermoed.

Twee keer op één middag stond de scanpoort rood zonder dat er iets gevonden was (op fc2d0a94 en op deze eigen PR). De joblogs op de forge wijzen beide keren dezelfde oorzaak aan, een halve seconde na de checkout:

curl: (22) The requested URL returned error: 504
[runner]: exitcode "22": failure

Op precies die commits zijn make check-secrets en make sast lokaal groen, en op de huidige main ook. Het was dus de download van een gepinde scanner die omviel, niet de repo.

Voor déze poort is dat de duurste faalvorm die er is: een rood beveiligingsvinkje dat geen vondst is, leert je het volgende rode vinkje ook weg te klikken. Dan staat de poort er nog wel, maar werkt hij niet meer.

Twee oorzaken, twee reparaties

De downloads herhalen op 5xx met een oplopende wachttijd. Deze poort haalt drie scanners van het net bij élke PR en élke push — even zo vaak een kans op een storing buiten deze repo.
Een opzijgezette run breekt netjes af in plaats van zich als failure te melden (concurrency per ref). Afbreken kost hier niets, en dat is geen aanname over snelheid maar een eigenschap van de meting: beide historie-scans lezen de héle historie, dus de latere run dekt onverkort wat de afgebroken run zou hebben gezien. Bij een poort die alléén de wijziging bekijkt zou dit juist fout zijn, en dat staat als waarschuwing in de workflow.

Dat Forgejo (16.0.1) de concurrency-sleutel slikt is gecontroleerd en niet aangenomen — de taak verscheen op deze PR, en in het runnerlog staat een nette RESULT_CANCELLED voor een opzijgezette taak. Een niet-herkende sleutel had de scan stil kunnen uitschakelen.

Een correctie op mezelf

In #801 schreef ik dat de scanners niet gecachet worden omdat drie minuten de staleness niet waard is. Dat was het zwakke argument. Het echte staat er nu: een cache-restore zou een sha256-geverifieerde download van een beveiligingsscanner vervangen door een artefact uit een eerdere run — en anders dan bij de toolchain in linux-gate.yml, waar check-toolchain de herstelde boom opnieuw toetst, is er hier geen tweede controle. Cachen zou precies de eigenschap opeten waar #778 om begonnen is.

make check groen.

Nazorg bij #778 / PR #799. **De aanleiding is gemeten, niet vermoed.** Twee keer op één middag stond de scanpoort rood zonder dat er iets gevonden was (op `fc2d0a94` en op deze eigen PR). De joblogs op de forge wijzen beide keren dezelfde oorzaak aan, een halve seconde na de checkout: ``` curl: (22) The requested URL returned error: 504 [runner]: exitcode "22": failure ``` Op precies die commits zijn `make check-secrets` en `make sast` lokaal groen, en op de huidige main ook. Het was dus de download van een gepinde scanner die omviel, niet de repo. Voor déze poort is dat de duurste faalvorm die er is: **een rood beveiligingsvinkje dat geen vondst is, leert je het volgende rode vinkje ook weg te klikken.** Dan staat de poort er nog wel, maar werkt hij niet meer. ### Twee oorzaken, twee reparaties 1. **De downloads herhalen op 5xx** met een oplopende wachttijd. Deze poort haalt drie scanners van het net bij élke PR en élke push — even zo vaak een kans op een storing buiten deze repo. 2. **Een opzijgezette run breekt netjes af** in plaats van zich als `failure` te melden (`concurrency` per ref). Afbreken kost hier niets, en dat is geen aanname over snelheid maar een eigenschap van de meting: beide historie-scans lezen de héle historie, dus de latere run dekt onverkort wat de afgebroken run zou hebben gezien. Bij een poort die alléén de wijziging bekijkt zou dit juist fout zijn, en dat staat als waarschuwing in de workflow. Dat Forgejo (16.0.1) de `concurrency`-sleutel slikt is gecontroleerd en niet aangenomen — de taak verscheen op deze PR, en in het runnerlog staat een nette `RESULT_CANCELLED` voor een opzijgezette taak. Een niet-herkende sleutel had de scan stil kunnen uitschakelen. ### Een correctie op mezelf In #801 schreef ik dat de scanners niet gecachet worden omdat drie minuten de staleness niet waard is. Dat was het zwakke argument. Het echte staat er nu: een cache-restore zou een sha256-geverifieerde download *van een beveiligingsscanner* vervangen door een artefact uit een eerdere run — en anders dan bij de toolchain in `linux-gate.yml`, waar `check-toolchain` de herstelde boom opnieuw toetst, is er hier geen tweede controle. Cachen zou precies de eigenschap opeten waar #778 om begonnen is. `make check` groen.

brenno changed title from ~~fix(scans): een opzijgezette run mag afbreken, niet rood worden~~ to fix(scans): de poort wordt niet meer rood om iets wat geen vondst is

2026-07-24 16:35:42 +00:00

brenno force-pushed fix/scans-concurrency from 66a2b65ff5

scans / scans (pull_request) Successful in 3m17s

Details

to dde666525c

scans / scans (pull_request) Successful in 3m13s

Details

2026-07-24 16:48:33 +00:00

Compare

brenno merged commit d812ede3da into main

2026-07-24 16:55:09 +00:00

brenno referenced this pull request from a commit