linux-gate wordt structureel afgebroken: 9 van de 27 post-merge-runs haalt het eind niet, en afbreken meldt zich als rood #1890

New issue

Closed

opened 2026-08-31 13:36:51 +00:00 by brenno · 0 comments

brenno commented

2026-08-31 13:36:51 +00:00

Owner

linux-gate.yml is sinds het terugdraaien van de per-PR-variant het enige dat
de volledige suite geautomatiseerd draait. In de praktijk haalt hij het eind
vaak niet.

Gemeten over de statussen van de laatste 80 commits op main (27 runs):

uitkomst	aantal
`success`	16
`failure` — "Has been cancelled"	9
`failure` — echt gefaald	2

Een op de drie runs wordt afgebroken. Voorbeelden:

2aae7b37d: gestart 09:02, afgebroken 09:15 — 13 minuten ver.
88fe28937: gestart 07:00, afgebroken 08:16 — 76 minuten ver, vlak voor het eind.
87ba6bcec: gestart 20:37, afgebroken 21:29.

Waarom

concurrency:
  group: linux-gate-${{ github.event_name }}-${{ github.ref }}
  cancel-in-progress: true

De run duurt 34 tot 74 minuten (gemeten over dezelfde 27 runs) op
linux-serial, capacity 1. Het merge-tempo op main is 15 tot 31 commits per
dag. Een nieuwe merge komt dus structureel binnen voordat de vorige run klaar
is, en zet hem opzij. De volgende merge doet hetzelfde met díe run. Dat is
uithongering, geen deduplicatie.

Het cancel-in-progress-argument is overgenomen van static-gate.yml, waar het
wél klopt: die poort is seconden per controle, bekijkt de héle boom op de
nieuwste commit, en de latere run dekt onverkort wat de afgebroken run zou
hebben gezien. Dat laatste geldt hier alleen als de latere run afloopt. Hij
loopt vaak niet af.

Bijeffect: rood op main betekent niets meer

Een afgebroken run meldt zich als failure. Negen van de elf rode
linux-gate-statussen op main zijn afbrekingen, niet defecten. Wie naar de
statuslijst kijkt ziet rood dat routinematig genegeerd moet worden — en dan
verdwijnen de twee échte fouten (ae01b918d, 8f79eb631, beide 29-08) in de
ruis. De detectielaag is er, maar hij alarmeert vals en wordt daardoor niet
gelezen.

Voorstel

cancel-in-progress: false voor de push-naar-main-trigger. Runs stapelen
dan op de capacity-1-runner, maar elke merge krijgt een uitspraak. Bij het
huidige tempo kan dat een achterstand opleveren; dat is informatie, geen
probleem — het zegt dat de poort niet meekomt.
Of: alleen de laatste van een reeks merges toetsen, maar dan bewust en
zichtbaar — bijvoorbeeld een run per uur op de kop van main in plaats van
per push. Dan is "één uitspraak per uur" een keuze in plaats van een
bijproduct van afbrekingen.
Hoe dan ook: een afgebroken run zou niet als failure mogen tellen. Als
Forgejo dat niet kan onderscheiden, is dat zelf een reden om niet af te
breken.

Zie ook de kop van linux-gate.yml, die de poort "detectie, geen preventie"
noemt. Dat klopt — maar detectie die twee van de drie keer wordt afgekapt is
ook geen detectie.

Gevonden bij een kritische review van het kwaliteitsbewakingssysteem, 31-08-2026.

`linux-gate.yml` is sinds het terugdraaien van de per-PR-variant het enige dat de volledige suite geautomatiseerd draait. In de praktijk haalt hij het eind vaak niet. Gemeten over de statussen van de laatste 80 commits op `main` (27 runs): | uitkomst | aantal | |---|---:| | `success` | 16 | | `failure` — **"Has been cancelled"** | **9** | | `failure` — echt gefaald | 2 | **Een op de drie runs wordt afgebroken.** Voorbeelden: - `2aae7b37d`: gestart 09:02, afgebroken 09:15 — 13 minuten ver. - `88fe28937`: gestart 07:00, afgebroken 08:16 — 76 minuten ver, vlak voor het eind. - `87ba6bcec`: gestart 20:37, afgebroken 21:29. ## Waarom ```yaml concurrency: group: linux-gate-${{ github.event_name }}-${{ github.ref }} cancel-in-progress: true ``` De run duurt **34 tot 74 minuten** (gemeten over dezelfde 27 runs) op `linux-serial`, capacity 1. Het merge-tempo op `main` is **15 tot 31 commits per dag**. Een nieuwe merge komt dus structureel binnen voordat de vorige run klaar is, en zet hem opzij. De volgende merge doet hetzelfde met díe run. Dat is uithongering, geen deduplicatie. Het `cancel-in-progress`-argument is overgenomen van `static-gate.yml`, waar het wél klopt: die poort is seconden per controle, bekijkt de héle boom op de nieuwste commit, en de latere run dekt onverkort wat de afgebroken run zou hebben gezien. Dat laatste geldt hier alleen als de latere run *afloopt*. Hij loopt vaak niet af. ## Bijeffect: rood op main betekent niets meer Een afgebroken run meldt zich als `failure`. Negen van de elf rode `linux-gate`-statussen op `main` zijn afbrekingen, niet defecten. Wie naar de statuslijst kijkt ziet rood dat routinematig genegeerd moet worden — en dan verdwijnen de twee échte fouten (`ae01b918d`, `8f79eb631`, beide 29-08) in de ruis. De detectielaag is er, maar hij alarmeert vals en wordt daardoor niet gelezen. ## Voorstel - `cancel-in-progress: false` voor de `push`-naar-`main`-trigger. Runs stapelen dan op de capacity-1-runner, maar elke merge krijgt een uitspraak. Bij het huidige tempo kan dat een achterstand opleveren; dat is informatie, geen probleem — het zegt dat de poort niet meekomt. - Of: alleen de laatste van een reeks merges toetsen, maar dan bewust en zichtbaar — bijvoorbeeld een run per uur op de kop van `main` in plaats van per push. Dan is "één uitspraak per uur" een keuze in plaats van een bijproduct van afbrekingen. - Hoe dan ook: een afgebroken run zou niet als `failure` mogen tellen. Als Forgejo dat niet kan onderscheiden, is dat zelf een reden om niet af te breken. Zie ook de kop van `linux-gate.yml`, die de poort "detectie, geen preventie" noemt. Dat klopt — maar detectie die twee van de drie keer wordt afgekapt is ook geen detectie. _Gevonden bij een kritische review van het kwaliteitsbewakingssysteem, 31-08-2026._

brenno added the

bug

label

2026-08-31 13:36:51 +00:00

brenno added the

in-progress

label

2026-08-31 15:23:07 +00:00

brenno referenced this issue from a commit

2026-08-31 15:37:53 +00:00

fix(ci): linux-gate afbreken, tijdsvervallende controles, release-poort, PDF-integratietest (#1890, #1892, #1893, #1894)

brenno referenced this issue