LibreKAT/Ocideck
LibreKAT/Ocideck
Watch
4
0
Fork
You've already forked Ocideck
 0
Code Issues 2 Pull requests Projects Releases 4 Packages Activity Actions

fix(ci): de vier oorzaken achter de faalmails van de GitHub-spiegel #966

Merged
brenno merged 4 commits from fix/ci-groen into main 2026-07-29 18:20:52 +00:00
Conversation 0 Commits 4 Files changed 8 +262 -118
brenno commented 2026-07-29 18:20:46 +00:00
Owner
Copy link

De faalmails van de GitHub-spiegel kwamen van vier oorzaken. Veertien gefaalde
draaien (27-07 t/m 29-07) teruggelezen; het beeld was consistent: de
Windows-leg viel bijna elke draai om, maar telkens op een ánder testgeval —
het patroon van een machine die traag is, niet van code die stuk is.

Oorzaak Draaien Waar
native_git_mirror_test — 3 min time-out, elke keer een ander geval 6 Windows
openkat_module_test — vaste 800 ms-pollus te krap 5 Linux en Windows
miauw_end_to_end_test — 30 s-time-out 2 Windows
mermaid_render_pipeline_test — "er is geen pagina geladen" 1 Windows
dart format op een niet-opgemaakt bestand 6 Linux (al opgelost, ac89350d)
gitleaks-download, curl-code 35 (TLS) 2 Linux
make licenses — fuchsia_remote_debug_protocol 2 Linux (al opgelost)

1 · Een echte vastloper in de git-laag

De belangrijkste vondst is geen testfout. NativeGitCli._spawn las de uitvoer
van git tot de stromen klaar waren, en die zijn pas klaar als de pijp sluit —
wat pas gebeurt als élk proces dat hem geërfd heeft weg is. Git start er zelf
een paar: een credential helper, git-remote-https. Overleeft zo'n kleinkind
zijn ouder, dan sluit de pijp niet mee en wachtte de aanroep daar onbegrensd
op: geen fout, geen resultaat, en geen tijdslimiet die nog kon vuren — die was
al afgezegd op het moment dat git zelf klaar was.

Op de Windows-CI strandde daar per draai een willekeurig git-testgeval drie
minuten op vast. In de app zou een git-handeling er even geruisloos in blijven
staan; dát is de reden dat dit onder Fixed staat en niet alleen onder de
testfixes.

De diagnose is eerst los van het project nagemeten: proces klaar na 4 ms, pijp
na 2 s nog open. De regressietest bootst dezelfde erfenis POSIX na (sh met
een achtergrondproces) en staat rood zonder de fix (10 s) en groen ermee
(2 s) — één keer gedraaid tegen de onherstelde code om dat te bewijzen.

2 · Drie tests die op de klok gokten

openkat_module_test (40 × 20 ms), mermaid_render_pipeline_test
(200 × 5 ms) en miauw_end_to_end_test (de standaard 30 s) wachtten met een
vast budget op echt werk. Dat getal is een gok op de snelheid van de machine —
precies waar test/support/pump_until.dart al voor waarschuwt. De eerste twee
wachten nu op de uitkomst in plaats van op de klok; de derde krijgt alleen op
Windows meer tijd, dezelfde afweging als in native_git_mirror_test (#933).

openkat_module_test viel óók op de Linux-poort om — het was dus geen
Windows-eigenaardigheid maar een testfout die daar het eerst zichtbaar werd.
Zijn tempmappen gaan meteen ook langs deleteTempDir; de Windows-log toonde
er de bekende errno 32 bij, die een geslaagd testgeval alsnog rood maakt.

3 · Herkansing op de gepinde scannerdownloads

Twee draaien strandden op curl-code 35 (TLS-handshake) bij het ophalen van
gitleaks. Vijf pogingen met drie seconden ertussen. De pin verzwakt niet:
wat er binnenkomt gaat onveranderd tegen de sha256 uit het checksums-bestand.

Wat er niet in zit

  • Format-check en make licenses stonden ook in de lijst, maar zijn al
    opgelost op main (respectievelijk ac89350d en de sbom/licence-tak van
    27-07). Nagemeten: make licenses is hier groen.
  • De 07-27-clusters (bulk_import_runner, image_service_coverage,
    slide_dedup_dialogs — tientallen gevallen per draai) waren de errno-32- en
    padscheidings-fouten die #933 wegnam. Sinds 28-07 niet meer teruggekomen.
  • De bewaker is hier bewust niet bij gehaald. Deze wijziging raakt geen van
    de vijf: geen bestandsformaat, geen opslag, geen afhankelijkheid, geen
    uitgaand verkeer of nieuw vertrouwde partij, geen publieke belofte. De
    git-wijziging zit wél in een geharde laag (§10.2), maar versoepelt daar
    niets: de argv-opbouw, het gesloten milieu, de tijdslimiet en de
    uitvoerbegrenzing blijven ongewijzigd. Het enige nieuwe gedrag is dat er na
    afloop van git nog maximaal 2 s op de pijp gewacht wordt in plaats van
    eeuwig — de uitvoer zelf is dan al gelezen, want die wordt gelezen zodra ze
    binnenkomt.
  • DAST (ZAP) is niet gedraaid: er verandert niets aan de webbundel of aan
    het geserveerde oppervlak.

Poorten

  • make check — groen (exit 0), 87,0% regeldekking, per-bestandsvloer 0 onder
    de grens.
  • make check-secrets — groen, 0 geverifieerde en 0 ongeverifieerde geheimen.
  • make sast — groen, 3 regels over 871 bestanden, 0 bevindingen.
De faalmails van de GitHub-spiegel kwamen van vier oorzaken. Veertien gefaalde draaien (27-07 t/m 29-07) teruggelezen; het beeld was consistent: de Windows-leg viel bijna elke draai om, maar telkens op een *ánder* testgeval — het patroon van een machine die traag is, niet van code die stuk is. | Oorzaak | Draaien | Waar | |---|---|---| | `native_git_mirror_test` — 3 min time-out, elke keer een ander geval | 6 | Windows | | `openkat_module_test` — vaste 800 ms-pollus te krap | 5 | Linux **en** Windows | | `miauw_end_to_end_test` — 30 s-time-out | 2 | Windows | | `mermaid_render_pipeline_test` — "er is geen pagina geladen" | 1 | Windows | | `dart format` op een niet-opgemaakt bestand | 6 | Linux (al opgelost, ac89350d) | | gitleaks-download, curl-code 35 (TLS) | 2 | Linux | | `make licenses` — `fuchsia_remote_debug_protocol` | 2 | Linux (al opgelost) | ## 1 · Een echte vastloper in de git-laag De belangrijkste vondst is geen testfout. `NativeGitCli._spawn` las de uitvoer van git tot de stromen klaar waren, en die zijn pas klaar als de pijp sluit — wat pas gebeurt als élk proces dat hem geërfd heeft weg is. Git start er zelf een paar: een credential helper, `git-remote-https`. Overleeft zo'n kleinkind zijn ouder, dan sluit de pijp niet mee en wachtte de aanroep daar **onbegrensd** op: geen fout, geen resultaat, en geen tijdslimiet die nog kon vuren — die was al afgezegd op het moment dat git zelf klaar was. Op de Windows-CI strandde daar per draai een willekeurig git-testgeval drie minuten op vast. In de app zou een git-handeling er even geruisloos in blijven staan; dát is de reden dat dit onder Fixed staat en niet alleen onder de testfixes. De diagnose is eerst los van het project nagemeten: proces klaar na 4 ms, pijp na 2 s nog open. De regressietest bootst dezelfde erfenis POSIX na (`sh` met een achtergrondproces) en staat **rood zonder de fix** (10 s) en groen ermee (2 s) — één keer gedraaid tegen de onherstelde code om dat te bewijzen. ## 2 · Drie tests die op de klok gokten `openkat_module_test` (40 × 20 ms), `mermaid_render_pipeline_test` (200 × 5 ms) en `miauw_end_to_end_test` (de standaard 30 s) wachtten met een vast budget op echt werk. Dat getal is een gok op de snelheid van de machine — precies waar `test/support/pump_until.dart` al voor waarschuwt. De eerste twee wachten nu op de uitkomst in plaats van op de klok; de derde krijgt alleen op Windows meer tijd, dezelfde afweging als in `native_git_mirror_test` (#933). `openkat_module_test` viel óók op de Linux-poort om — het was dus geen Windows-eigenaardigheid maar een testfout die daar het eerst zichtbaar werd. Zijn tempmappen gaan meteen ook langs `deleteTempDir`; de Windows-log toonde er de bekende errno 32 bij, die een geslaagd testgeval alsnog rood maakt. ## 3 · Herkansing op de gepinde scannerdownloads Twee draaien strandden op curl-code 35 (TLS-handshake) bij het ophalen van gitleaks. Vijf pogingen met drie seconden ertussen. **De pin verzwakt niet:** wat er binnenkomt gaat onveranderd tegen de sha256 uit het checksums-bestand. ## Wat er niet in zit * **Format-check en `make licenses`** stonden ook in de lijst, maar zijn al opgelost op main (respectievelijk `ac89350d` en de sbom/licence-tak van 27-07). Nagemeten: `make licenses` is hier groen. * **De 07-27-clusters** (bulk_import_runner, image_service_coverage, slide_dedup_dialogs — tientallen gevallen per draai) waren de errno-32- en padscheidings-fouten die #933 wegnam. Sinds 28-07 niet meer teruggekomen. * **De bewaker is hier bewust niet bij gehaald.** Deze wijziging raakt geen van de vijf: geen bestandsformaat, geen opslag, geen afhankelijkheid, geen uitgaand verkeer of nieuw vertrouwde partij, geen publieke belofte. De git-wijziging zit wél in een geharde laag (§10.2), maar versoepelt daar niets: de argv-opbouw, het gesloten milieu, de tijdslimiet en de uitvoerbegrenzing blijven ongewijzigd. Het enige nieuwe gedrag is dat er na afloop van git nog maximaal 2 s op de pijp gewacht wordt in plaats van eeuwig — de uitvoer zelf is dan al gelezen, want die wordt gelezen zodra ze binnenkomt. * **DAST (ZAP)** is niet gedraaid: er verandert niets aan de webbundel of aan het geserveerde oppervlak. ## Poorten * `make check` — groen (exit 0), 87,0% regeldekking, per-bestandsvloer 0 onder de grens. * `make check-secrets` — groen, 0 geverifieerde en 0 ongeverifieerde geheimen. * `make sast` — groen, 3 regels over 871 bestanden, 0 bevindingen.
NativeGitCli._spawn las de uitvoer van git tot de stromen klaar waren, en
die zijn pas klaar als de pijp sluit — wat pas gebeurt als élk proces dat
hem geërfd heeft weg is. Git start er zelf een paar: een credential
helper, `git-remote-https`. Overleeft zo'n kleinkind zijn ouder, dan sluit
de pijp niet mee met git en wachtte de aanroep daar onbegrensd op.

Dat is de ergste vorm van stuk: geen fout, geen resultaat, en geen
tijdslimiet die nog kan vuren — die was al afgezegd op het moment dat git
zelf klaar was. Op de Windows-CI strandde daar per draai een willekeurig
git-testgeval drie minuten op vast, elke keer een ander; in de app zou een
git-handeling er even geruisloos in blijven staan.

Na afloop wordt nu nog kort (2 s) op de pijp gewacht en anders losgelaten,
met een waarschuwing in de log. Wat er tot dan gelezen is, is het
antwoord; op de gewone weg sluit de pijp tegelijk met het proces en
verandert er niets.

De regressietest bootst de erfenis POSIX na (`sh` met een
achtergrondproces) en staat rood zonder deze wijziging: 10 s in plaats van
2 s. De diagnose is los van het project nagemeten — proces klaar na 4 ms,
pijp na 2 s nog open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drie testgevallen wachtten met een vast aantal rondes op echt werk, en dat
getal is een gok op de snelheid van de machine. Op de Windows-leg, waar de
hele suite tegelijk om vier kernen vecht, was de gok soms te krap — en dan
staat er rood bij code waar niets mis mee is. `openkat_module_test` viel
daar ook op de Linux-poort op om; het is dus geen Windows-eigenaardigheid
maar een testfout die daar het eerst zichtbaar wordt.

* `openkat_module_test` wachtte 40 × 20 ms op een mapscan. Nu `pumpUntil`
  uit test/support/, dat op de voorwaarde wacht en met een leesbare reden
  faalt als die nooit waar wordt. De tempmappen gaan meteen ook langs
  `deleteTempDir`: de Windows-log toonde er de bekende errno 32 bij, die
  een geslaagd testgeval alsnog rood maakt.
* `mermaid_render_pipeline_test` wachtte 200 × 5 ms tot de mermaid-bundel
  geladen was. Nu een wandklokgrens die afbreekt zodra de pagina er is —
  op een gezonde machine kost dat niets. Eén keer wachten volstaat: er
  wordt precies één keer per proces gebootstrapt.
* `miauw_end_to_end_test` doet echt werk van begin tot eind (sjabloon
  parsen, verzegelen, versleutelde zip bouwen) en kreeg daar op Windows
  meer dan de standaard dertig seconden voor. Elders blijft de strakke
  standaard staan, zodat een échte vastloper snel opvalt — dezelfde
  afweging als in native_git_mirror_test (#933).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De gitleaks- en trufflehog-stappen halen een release van github.com, en
die verbinding valt af en toe om: de poort strandde twee keer op
curl-code 35 (TLS-handshake), tien minuten werk verderop en zonder dat er
iets met de code mis was. Een faalmail voor een netwerkhikje leert
niemand iets, en het maakt de mails die er wél toe doen minder
geloofwaardig.

Vijf pogingen met drie seconden ertussen. Dit verzwakt de pin niet: wát
er binnenkomt gaat onveranderd tegen de sha256 uit het checksums-bestand.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs(changelog): leg de vier faaloorzaken van de spiegel-CI vast
All checks were successful
scans / scans (pull_request) Successful in 3m22s
Details
bb1846caec 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
brenno merged commit d26a791236 into main 2026-07-29 18:20:52 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
accepted
Assessed and will be built

  
bug
Something is broken

  
declined
Assessed and will not be built

  
docs
Documentation only

  
duplicate
Already tracked elsewhere

  
enhancement
New feature or improvement request

  
good first issue
Small, self-contained, and a good place to start

  
in-progress
Someone is working on this right now. Do not start it in parallel.

  
needs-info
Waiting for the reporter

  
privacy
Personal data can leak. Handled before anything else.

  
security
A weakness someone could use. Handled before anything else.

  
triage
Awaiting assessment

No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
LibreKAT/Ocideck!966
No description provided.