Revert "ci: schrijf een echte commit-status voor de static-gate" (#1260) #1261

Merged

brenno merged 1 commit from revert/1260-ci-status-bridge into main

2026-08-05 09:48:08 +00:00

brenno commented

2026-08-05 09:40:08 +00:00

Owner

Wat

Revert van PR #1260. De bridge-stap bleek onnodig: de CI werkte al.

Waarom

De aanleiding voor #1260 was een verkeerde diagnose. Een Actions-run op Forgejo/Gitea 1.22 schrijft per-entry state: null, maar de combined commit-status berekent wél correct success uit het status-veld — en dát is wat branch-bescherming leest. PR #1259 werd geblokkeerd bij een merge-poging omdat ik merge-de terwijl de static-gate-run nog pending was; de run werd ~4 min later groen en een normale merge had toen gewerkt. Bewezen: PR #1258 en #1260 mergeden normaal zodra de run klaar was.

De pr-landen-skill beweerde bovendien "er is geen CI-runner, wachten heeft geen zin" — onwaar, en de reden dat ik de poll-stap oversloeg. Die skill wordt apart gecorrigeerd.

De bridge-stap is niet schadelijk, maar pure redundantie: een extra API-call en extra status-context per PR voor een gate die al werkte.

Testplan

make check lokaal groen (revert is een zuivere bestandsomkering)
static-gate-run op deze PR groen — ik poll de combined status tot hij niet meer pending is, en merge pas dan (de correcte procedure)

Generated with Devin

## Wat Revert van PR #1260. De bridge-stap bleek onnodig: de CI werkte al. ## Waarom De aanleiding voor #1260 was een verkeerde diagnose. Een Actions-run op Forgejo/Gitea 1.22 schrijft per-entry `state: null`, maar de **combined** commit-status berekent wél correct `success` uit het `status`-veld — en dát is wat branch-bescherming leest. PR #1259 werd geblokkeerd bij een merge-poging omdat ik merge-de **terwijl de static-gate-run nog `pending` was**; de run werd ~4 min later groen en een normale merge had toen gewerkt. Bewezen: PR #1258 en #1260 mergeden normaal zodra de run klaar was. De `pr-landen`-skill beweerde bovendien *"er is geen CI-runner, wachten heeft geen zin"* — onwaar, en de reden dat ik de poll-stap oversloeg. Die skill wordt apart gecorrigeerd. De bridge-stap is niet schadelijk, maar pure redundantie: een extra API-call en extra status-context per PR voor een gate die al werkte. ## Testplan - [x] `make check` lokaal groen (revert is een zuivere bestandsomkering) - [ ] static-gate-run op deze PR groen — ik poll de combined status tot hij niet meer `pending` is, en merge pas dan (de correcte procedure) Generated with [Devin](https://devin.ai)

brenno added 1 commit

2026-08-05 09:40:09 +00:00

Revert "ci: schrijf een echte commit-status voor de static-gate (werkt om Gitea 1.22-bug)"

scans / scans (pull_request) Successful in 1m46s

Details

static-gate / static-gate (pull_request) Successful in 4m24s

Details

edaba39b8c

Deze revert draait PR #1260 terug. De bridge-stap bleek onnodig: de CI
werkte al. Een Actions-run op Forgejo/Gitea 1.22 schrijft per-entry
`state: null`, maar de combined commit-status berekent wél correct
`success` uit het `status`-veld — en dát is wat branch-bescherming leest.

De aanleiding voor #1260 was een verkeerde diagnose: PR #1259 werd
geblokkeerd bij een merge-poging, en ik concludeerde dat de status-check
structureel kapot was. In werkelijkheid probeerde ik te mergen terwijl de
static-gate-run nog `pending` was — de run werd ~4 min later groen, en een
normale merge had toen gewerkt (bewezen: PR #1258 en #1260 mergeden
normaal zodra de run klaar was). De `pr-landen`-skill beweerde bovendien
"er is geen CI-runner, wachten heeft geen zin", wat onwaar is en mij de
poll-stap liet overslaan. Die skill wordt apart gecorrigeerd.

De bridge-stap zelf is niet schadelijk, maar wel pure redundantie: een
extra API-call en een extra status-context per PR, voor een gate die al
werkte. Weg ermee.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>