CI: release-scripts-job is flaky op de runner #137

New issue

Closed

opened 2026-07-19 21:55:46 +00:00 by robbertbos · 1 comment

robbertbos commented

2026-07-19 21:55:46 +00:00

Owner

De CI / release-scripts-job faalde op 2026-07-19 drie keer op drie verschillende heads (renovate/nldd, fase-1-fundament-v2 921ba9c, en de migratie-test-branch 8919ecf), terwijl bash .forgejo/scripts/test-release-scripts.sh lokaal tegen exact die heads groen is en de job op de runner tussendoor ook meermaals slaagde (o.a. #127, herkansing #124).

De scripts zelf zijn puur bash, deterministisch, zonder jq/curl/sudo-afhankelijkheid. De failures vallen samen met drukte op de runner (meerdere parallelle runs), dus vermoedelijk een runner-/checkout-probleem, geen scriptfout. Logs zijn via de API niet op te halen (404); bij een volgende failure de web-UI-log bekijken en de oorzaak hier noteren.

De `CI / release-scripts`-job faalde op 2026-07-19 drie keer op drie verschillende heads (renovate/nldd, fase-1-fundament-v2 `921ba9c`, en de migratie-test-branch `8919ecf`), terwijl `bash .forgejo/scripts/test-release-scripts.sh` lokaal tegen exact die heads groen is en de job op de runner tussendoor ook meermaals slaagde (o.a. #127, herkansing #124). De scripts zelf zijn puur bash, deterministisch, zonder jq/curl/sudo-afhankelijkheid. De failures vallen samen met drukte op de runner (meerdere parallelle runs), dus vermoedelijk een runner-/checkout-probleem, geen scriptfout. Logs zijn via de API niet op te halen (404); bij een volgende failure de web-UI-log bekijken en de oorzaak hier noteren.

robbertbos referenced this issue from a commit

2026-07-21 05:24:57 +00:00

Retry flaky release-scripts CI job under concurrent load

robbertbos referenced this issue from a pull request that will close it,

2026-07-21 05:25:15 +00:00

Retry flaky release-scripts CI job under concurrent load #147

robbertbos referenced this issue from a commit

2026-07-21 05:26:18 +00:00

Retry flaky release-scripts CI job under concurrent load

robbertbos commented

2026-07-21 05:26:43 +00:00

Author

Owner

Oorzaak gevonden

De duur-analyse via de tasks-API gaf de eerste hint: alle failures duren 9-11s, identiek aan de geslaagde runs (~10s). Een gecrashte checkout zou vroeg falen; de job draaide dus volledig en gaf pas aan het eind exit 1. Niet de checkout, maar de teststap.

De web-UI-log van de gefaalde attempt (run 1255, attempt 1) wees de check aan:

ok   - changelog finds v2026.5.18      <- exit-code check: exit 0
FAIL - v2026.5.18 section is empty     <- zelfde aanroep, ms later: lege output

Twee aanroepen van het deterministische changelog-section.sh (zelfde arg, zelfde CHANGELOG.md) geven binnen één run verschillende output. Dat kan alleen als het bestand tussendoor wijzigt (gedeelde-workspace-race) of awk intermitterend gekild wordt onder geheugendruk (set -e op de command-substitution -> exit non-zero, lege stdout). Beide zijn transient contentie-fouten in de teststap, geen scriptfout in de logica - dezelfde klasse als de e2e-poortbotsing op deze capacity=2/host-networked runner.

Fix

PR #147: de teststap draait nu in een 3x retry-loop en dumpt de CHANGELOG-staat (wc -l + eerste regel) op een gefaalde poging, zodat een volgende failure te duiden is zonder de auth-gated runner-logs (die inderdaad 404 gaven, zoals hier al gemeld).

## Oorzaak gevonden De duur-analyse via de tasks-API gaf de eerste hint: alle failures duren 9-11s, identiek aan de geslaagde runs (~10s). Een gecrashte checkout zou vroeg falen; de job draaide dus volledig en gaf pas aan het eind exit 1. Niet de checkout, maar de teststap. De web-UI-log van de gefaalde attempt (run 1255, attempt 1) wees de check aan: ``` ok - changelog finds v2026.5.18 <- exit-code check: exit 0 FAIL - v2026.5.18 section is empty <- zelfde aanroep, ms later: lege output ``` Twee aanroepen van het deterministische `changelog-section.sh` (zelfde arg, zelfde CHANGELOG.md) geven binnen één run verschillende output. Dat kan alleen als het bestand tussendoor wijzigt (gedeelde-workspace-race) of awk intermitterend gekild wordt onder geheugendruk (`set -e` op de command-substitution -> exit non-zero, lege stdout). Beide zijn transient contentie-fouten in de teststap, geen scriptfout in de logica - dezelfde klasse als de e2e-poortbotsing op deze `capacity=2`/host-networked runner. ## Fix PR #147: de teststap draait nu in een 3x retry-loop en dumpt de CHANGELOG-staat (`wc -l` + eerste regel) op een gefaalde poging, zodat een volgende failure te duiden is zonder de auth-gated runner-logs (die inderdaad 404 gaven, zoals hier al gemeld).

robbertbos referenced this issue from a commit

2026-07-21 05:45:29 +00:00

Retry the flaky release-scripts CI job

robbertbos referenced this issue from a commit

2026-07-21 05:45:44 +00:00

Retry the flaky release-scripts CI job

robbertbos closed this issue

2026-07-21 06:10:37 +00:00