Scheid kritieke release-CI van asynchrone website-synchronisatie #2302

New issue

Closed

opened 2026-10-05 23:42:44 +00:00 by brenno · 0 comments

brenno commented

2026-10-05 23:42:44 +00:00

Owner

Aanleiding

Website-downloads bijwerken is in de workflow een stap na publicatie met een handmatige fallback. release_auto gebruikt die stap tegelijk als voltooiingsmarker voor de hele release en blokkeert fase 3 op elke failure. Een SSH/pushfout van de website kan daardoor de cryptografische handtekening en webdemo blokkeren terwijl alle releaseartefacten al correct gepubliceerd zijn.

Na een succesvolle push naar de website-repo wacht release_auto bovendien slechts zes minuten op diens eigen asynchrone deploy. Een normale wachtrij wordt daarna als verkeerde DNS/host uitgelegd met advies opnieuw te publiceren.

Bewijs

.forgejo/workflows/release.yml:887-895 noemt website-downloads een post-publicatiestap met handmatige fallback.
scripts/release_auto.sh:330-358 gebruikt die job als completion marker.
scripts/release_auto.sh:1103-1109 blokkeert fase 3 op elke terminale fout.
scripts/release_auto.sh:1255-1265 wacht 24 maal 15 seconden en adviseert daarna herpublicatie.

Gewenst gedrag

Definieer expliciet welke jobs de artefactpublicatie schrijven en kritisch zijn.
Fase 3 mag starten zodra die kritieke jobs terminaal groen zijn.
Website-sync blijft verplicht vóór het eindbericht, maar wordt afzonderlijk gevolgd en hersteld.
Een nog lopende of onbekende externe deploy wordt nooit als verkeerde host of mislukking gepresenteerd.
Geen tweede publicatie zolang de eerste externe deploy actief kan zijn.

Regressietoets

Een rode website-sync na groene artefactjobs blokkeert tekenen/deploy van de release niet maar verhindert wel klaar melden. Een externe deploy die na meer dan zes minuten groen/live wordt veroorzaakt geen herpublicatie.

## Aanleiding Website-downloads bijwerken is in de workflow een stap na publicatie met een handmatige fallback. release_auto gebruikt die stap tegelijk als voltooiingsmarker voor de hele release en blokkeert fase 3 op elke failure. Een SSH/pushfout van de website kan daardoor de cryptografische handtekening en webdemo blokkeren terwijl alle releaseartefacten al correct gepubliceerd zijn. Na een succesvolle push naar de website-repo wacht release_auto bovendien slechts zes minuten op diens eigen asynchrone deploy. Een normale wachtrij wordt daarna als verkeerde DNS/host uitgelegd met advies opnieuw te publiceren. ## Bewijs - .forgejo/workflows/release.yml:887-895 noemt website-downloads een post-publicatiestap met handmatige fallback. - scripts/release_auto.sh:330-358 gebruikt die job als completion marker. - scripts/release_auto.sh:1103-1109 blokkeert fase 3 op elke terminale fout. - scripts/release_auto.sh:1255-1265 wacht 24 maal 15 seconden en adviseert daarna herpublicatie. ## Gewenst gedrag - Definieer expliciet welke jobs de artefactpublicatie schrijven en kritisch zijn. - Fase 3 mag starten zodra die kritieke jobs terminaal groen zijn. - Website-sync blijft verplicht vóór het eindbericht, maar wordt afzonderlijk gevolgd en hersteld. - Een nog lopende of onbekende externe deploy wordt nooit als verkeerde host of mislukking gepresenteerd. - Geen tweede publicatie zolang de eerste externe deploy actief kan zijn. ## Regressietoets Een rode website-sync na groene artefactjobs blokkeert tekenen/deploy van de release niet maar verhindert wel klaar melden. Een externe deploy die na meer dan zes minuten groen/live wordt veroorzaakt geen herpublicatie.

brenno added the

release-blocker

bug

accepted

labels

2026-10-05 23:42:44 +00:00

brenno referenced this issue from a commit

2026-10-06 22:31:25 +00:00

fix(release): externe website-deploy afzonderlijk volgen (#2302)

brenno referenced this issue

2026-10-06 22:31:32 +00:00

fix(release): externe website-deploy afzonderlijk volgen (#2302) #2335