feat(ci): web-gate bouwt de webbundel op een PR die hem kan breken (#1888-staart) #1905
No reviewers
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck!1905
Loading…
Reference in a new issue
No description provided.
Delete branch "ci/web-gate"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Wat dit toevoegt
make check-webis de enige controle die naar een gebouwde webbundel kijkt. Hij draaide op twee plekken: lokaal incheck-full, en inrelease.ymlop eenv*-tag. Tussen die twee bouwde niets de web.Dat is het gat waar #1888 doorheen viel. De dotfile-opruiming daar hield als "bewust meegenomen" alleen aan wat
releaseArtefactennoemt — een lijst die beschrijft wat de inpakstap er zelf bij legt, niet wat de bundel bevat. De twee dotfiles die er wél horen komen uitweb/en worden doorflutter build webgekopieerd. Weg warenbuild/web/.htaccess(#849) enbuild/web/.well-known/security.txt(RFC 9116). De eerste machine die dat merkte was fase 1 van de v0.5.0-release, weken na de merge. Alle poorten stonden intussen groen.De reparatie zelf zit in #1903. Dit is het tweede stuk: de bouw naar links schuiven.
De tegenproef
web-gatezou zijn afgegaan op de PR van #1888 zelf — die raakttool/pack_web_release.dart, dat in het padfilter staat — enmake check-webwas daar rood geworden op de ontbrekende.htaccess. Vóór de merge, niet weken later.Wat het kost
Over de laatste 200 merges naar
mainzou hij 31 keer zijn afgegaan (15%, ongeveer 1 op 7). Per ingang:pubspec.yamlMakefile--no-web-resources-cdn,--csp)pubspec.locktool/pack_web_release.darttool/check_web_hardening.dart.tool-versionsweb/**tool/check_bundled_docs_fresh.dartcheck-web.forgejo/ci-image/**docs/**staat er bewust niet op: de gebundelde-docs-controle bestaat voor incrementele builds, en CI bouwt altijd schoon.Bewust géén vereiste check
Branch-bescherming wacht op elke context die zij eist. Een vereiste check met een padfilter meldt zich niet op een PR die die paden niet raakt, en dan hangt die PR eeuwig
pending.web-gategaat dus niet instatus_check_contexts;static-gateenscansblijven de vereiste, filterloze poorten. Rood is hier in de praktijk nog steeds blokkerend — je merget er niet overheen — het is alleen niet het mechanisme waar de bescherming op wacht. Dat staat in de kop van de workflow én indocs/CHECKS.md, want het is precies het soort ding dat iemand over een jaar "netjes" wil aanzetten.Het padfilter is zelf bewaakt
Een poort die niet afgaat bewaakt niets — zo viel
.tool-versionsooit uit het filter vanlinux-build.yml.test/web_gate_triggers_test.dartontleedt de workflow en eist per trekker dat elke ingang op de lijst staat, met de reden erbij, plus dat de twee lijsten niet uiteenlopen.Dat "per trekker" is geen netheid. Mijn eerste versie deed
tekst.contains(...)over het hele bestand, en die overleefde de mutatie: een pad weghalen uit alleen hetpull_request-filter bleef groen omdat het bijpushnog stond. Zeven mutaties na de herschrijving, zeven keer rood:web/**uit beide filterspushwegmake check-webpull_request-trekker wegHerstel telkens uit een kopie, niet met
git checkout; het bestand is na afloop byte-identiek.En dezelfde fout die #1888 maakte, één laag hoger
test/dartcv_cache_key_test.darthad een handgepinde lijst van drie workflows. Mijn nieuwe workflow gebruikt diezelfde cache, dus ik kon er een vierde regel bij zetten — en dan staat de volgende er weer buiten. Dat is letterlijk de faalvorm van #1888: een lijst die het domein beschrijft maar niet afleidt.De lijst wordt nu afgeleid uit de workflowmap. Een goedkoop tekstaftasten bepaalt het domein, het ontleden doet de controle, en dat die twee gelijk blijven is zelf een test — anders slaagt de invariant vacuüm zodra de ontleder stil een bestand laat vallen. Er staat ook een
isNotEmpty-regel onder: zonder die regel slaagt de hele suite zodra de afleiding niets meer vindt.Bewijs dat de afleiding de nieuwe workflow écht dekt:
restore-keysterugzetten inweb-gate's cachestap maakt de test rood op precies die workflow, zonder dat er een regel is bijgezet.Toetsing
docs/CHECKS.mdlossen op, inclusief de nieuwe.make checkgroen..forgejo/workflows/web-gate.yml, dat in zijn eigen padfilter staat — de poort gaat dus af op zijn eigen PR. Dat is de enige echte proef dat Forgejo de workflow accepteert enmake check-webin dat image draait; ik merge pas als die run groen is.Bewaker
Raakt geen formaat, geen opslag, geen afhankelijkheid. Uitgaand verkeer: geen nieuwe partij — het CI-image,
actions/checkout@v4/actions/cache@v4en de Flutter-webengine-download waren al in gebruik instatic-gate.ymlenrelease.yml.Wat het wél raakt is een publieke belofte in de documentatie:
docs/CHECKS.mdbeweert vanaf nu dat de webbundel per PR gebouwd en gecontroleerd wordt. Die claim is precies zoveel waard als de workflow echt draait, en een claim over een poort is niet zelf gepoort — dat is de blinde vlek uit #1886–#1895. Daarom hangt het merge-moment aan de smoke-run hierboven en niet aan mijn lezing van de YAML. De richting is verder herstellend: er wordt een controle toegevoegd, niets versoepeld, en de reden waarom deze poort géén vereiste check is staat opgeschreven in plaats van stilzwijgend te blijven.Co-Authored-By: Claude Opus 5 noreply@anthropic.com
893c2abb18cb97e5dc28