scans-poort is ~50% flaky op de forge

brenno commented

2026-08-03 15:11:49 +00:00

Owner

De scans-workflow (secrets: gitleaks/trufflehog + SAST: semgrep) faalt intermitterend op de forge, onafhankelijk van de wijziging. Waargenomen rond de v0.2.0-cut:

run#2558 (262b1e5e) FAIL, run#2556 (6b69bc3e) OK, run#2551 (c1b1dca3, mijn release-PR) FAIL, run#2548 (33a663f6, main-lineage) FAIL, run#2543 (7d14fc06) OK, run#2538 OK — grofweg 50/50 op vergelijkbare commits.
Lokaal draaien make check-secrets én make sast groen op exact dezelfde boom (0 secrets, 0 findings), dus het is geen echte vondst maar infrastructuur/non-determinisme.
scans is géén required merge-check (alleen static-gate is dat), dus het blokkeert niet — maar een poort die de helft van de tijd rood staat, traint iedereen om rood te negeren, en dán mist hij een echte vondst.

Mogelijk gerelateerd aan het net gewijzigde voorgebakken scan-image (#1150). Vraag: diagnosticeer de flake (netwerk/tool-non-determinisme in de container) en maak 'm betrouwbaar, of isoleer het flaky deel. Doel: scans is óf betrouwbaar groen óf een echte, actie-waardige rode.

De `scans`-workflow (secrets: gitleaks/trufflehog + SAST: semgrep) faalt intermitterend op de forge, onafhankelijk van de wijziging. Waargenomen rond de v0.2.0-cut: - run#2558 (262b1e5e) FAIL, run#2556 (6b69bc3e) OK, run#2551 (c1b1dca3, mijn release-PR) FAIL, run#2548 (33a663f6, main-lineage) FAIL, run#2543 (7d14fc06) OK, run#2538 OK — grofweg 50/50 op vergelijkbare commits. - Lokaal draaien `make check-secrets` én `make sast` groen op exact dezelfde boom (0 secrets, 0 findings), dus het is geen echte vondst maar infrastructuur/non-determinisme. - `scans` is géén *required* merge-check (alleen `static-gate` is dat), dus het blokkeert niet — maar een poort die de helft van de tijd rood staat, traint iedereen om rood te negeren, en dán mist hij een echte vondst. Mogelijk gerelateerd aan het net gewijzigde voorgebakken scan-image (#1150). Vraag: diagnosticeer de flake (netwerk/tool-non-determinisme in de container) en maak 'm betrouwbaar, of isoleer het flaky deel. Doel: scans is óf betrouwbaar groen óf een echte, actie-waardige rode.

brenno added the

bug

label

2026-08-03 15:11:49 +00:00

brenno added the

in-progress

label

2026-08-03 18:10:01 +00:00

brenno commented

2026-08-03 18:10:01 +00:00

Author

Owner

Opgepakt: ik ga de daadwerkelijke faaluitvoer van een gefaalde scans-run ophalen (niet gissen) en tegen een geslaagde run leggen. Diagnose eerst, dan pas een fix.

brenno commented

2026-08-03 18:30:09 +00:00

Author

Owner

Gediagnosticeerd én opgelost. Het was geen flake maar een deterministische breuk die zich als een flake voordeed.

Diagnose (met bewijs uit de runner-logs):

Lokaal zijn de scanners deterministisch en schoon: 3×3 make check-secrets+make sast → exit 0, geen findings. Het lag dus niet aan de tools.
De /actions/tasks-statusveld is onbetrouwbaar (meldde runs als 'failure' die volgens /actions/runs/{n}/jobs gewoon slaagden). De echte grond-waarheid: de commit-status en de job-logs.
Historisch stond scans honderden runs groen (±2080–2540); pas de laatste ~dag ontstond een cluster rood — een recente regressie, samenvallend met #1150 (voorgebakken scan-image).
Commit-status-omschrijving: 'Failing after 4-6s' — veel te snel voor de scan zelf (±17s + volledige-historie-checkout), dus het faalde in de eerste stap.
Logbewijs (run 2561): docker pull …/ocideck-scans:gl8.30.1-th3.95.9-sg1.171.0 → Error response from daemon: … not found. Het voorgebakken scan-image bestond niet in de registry.
Takken die vóór #1150 waren afgesplitst draaiden nog de oude apt-cache-scans.yml en slaagden (runs 2558/2563) — vandaar de ~50%-illusie. Een enkele echte 'failure' was daarnaast een concurrency-cancellation (run 2572: context canceled).

Oorzaak: #1150 mergede de nieuwe scans.yml (die het image pullt) plus ci-image-scans.yml, maar het image is nooit gepubliceerd — Forgejo draait een net-toegevoegde push-workflow niet op de introducerende commit, en niemand dispatchte hem daarna. Precies de valkuil uit de projectkennis 'scans-image eerst publiceren'.

Fix: ci-image-scans.yml op main gedispatcht → job build-publish (run 2583) groen: image gebouwd + gepusht. Daarna zijn de PR-scans-runs weer groen (2584, 2586 op verse commits), waar post-#1150-takken eerder 'not found' faalden.

Recidive: géén. De push-trigger van ci-image-scans.yml staat op o.a. .github/pinned-ci-versions.json, dus een volgende pin-bump herpubliceert het image automatisch. Dit was een eenmalig uitrol-gat, nu gedicht.

Bestaande open PR's met rode scans worden groen zodra hun scans opnieuw draait (nieuwe commit of re-run); scans is geen required check, dus het blokkeerde niets. Sluit dit issue.

Gediagnosticeerd én opgelost. **Het was geen flake maar een deterministische breuk die zich als een flake voordeed.** **Diagnose (met bewijs uit de runner-logs):** - Lokaal zijn de scanners deterministisch en schoon: 3×3 `make check-secrets`+`make sast` → exit 0, geen findings. Het lag dus niet aan de tools. - De `/actions/tasks`-statusveld is onbetrouwbaar (meldde runs als 'failure' die volgens `/actions/runs/{n}/jobs` gewoon slaagden). De echte grond-waarheid: de commit-status en de job-logs. - Historisch stond scans honderden runs groen (±2080–2540); pas de laatste ~dag ontstond een cluster rood — een **recente regressie**, samenvallend met #1150 (voorgebakken scan-image). - Commit-status-omschrijving: **'Failing after 4-6s'** — veel te snel voor de scan zelf (±17s + volledige-historie-checkout), dus het faalde in de eerste stap. - Logbewijs (run 2561): `docker pull …/ocideck-scans:gl8.30.1-th3.95.9-sg1.171.0 → Error response from daemon: … not found`. **Het voorgebakken scan-image bestond niet in de registry.** - Takken die vóór #1150 waren afgesplitst draaiden nog de oude apt-cache-scans.yml en slaagden (runs 2558/2563) — vandaar de ~50%-illusie. Een enkele echte 'failure' was daarnaast een concurrency-cancellation (run 2572: `context canceled`). **Oorzaak:** #1150 mergede de nieuwe scans.yml (die het image pullt) plus `ci-image-scans.yml`, maar het image is nooit gepubliceerd — Forgejo draait een net-toegevoegde `push`-workflow niet op de introducerende commit, en niemand dispatchte hem daarna. Precies de valkuil uit de projectkennis 'scans-image eerst publiceren'. **Fix:** `ci-image-scans.yml` op `main` gedispatcht → job `build-publish` (run 2583) groen: image gebouwd + gepusht. Daarna zijn de PR-scans-runs weer groen (2584, 2586 op verse commits), waar post-#1150-takken eerder 'not found' faalden. **Recidive:** géén. De `push`-trigger van `ci-image-scans.yml` staat op o.a. `.github/pinned-ci-versions.json`, dus een volgende pin-bump herpubliceert het image automatisch. Dit was een eenmalig uitrol-gat, nu gedicht. Bestaande open PR's met rode scans worden groen zodra hun scans opnieuw draait (nieuwe commit of re-run); scans is geen required check, dus het blokkeerde niets. Sluit dit issue.

brenno

2026-08-03 18:30:10 +00:00

closed this issue
removed the
in-progress
label

brenno referenced this issue

2026-08-03 20:23:08 +00:00

docs(release): documenteer de ketenverbeteringen #1184

brenno referenced this issue from a commit

2026-08-03 20:23:09 +00:00

docs(release): documenteer de ketenverbeteringen (#1169/#1170/#1172, #1168)

Rows
Columns

scans-poort is ~50% flaky op de forge #1168