Release publikuje svá metadata na web dřív, než přistane jeho záznam, a web se nikdy nevrací o release zpět

131. Release publikuje svá metadata na web dříve, než přistane jeho záznam, a web se nikdy nevrací o release zpět

Kontext

Instalátor čte dva soubory z majordomus.dev: releases/latest.json a releases/<tag>.json. Oba jsou projekce záznamu release a dosud se na web dostaly jedině tak, že pull request záznamu přistál na masteru a master byl nasazen.

Změřeno 2026-10-10:

• v0.19.1 byla publikována na GitHubu v 01:46Z. Její záznamový pull request (#866) spouštěl ci 106 minut, dané shardem sady o 86 minutách, a byl sloučen v 07:09Z.
• v0.20.0 byla otagována v 16:14Z a publikována v 16:38Z. Její publish job zemřel před navržením záznamu, záznam byl navržen ručně v 17:23Z, sloučen v 17:25Z bez čekání na jeho ci na slovo vlastníka a web servíroval 0.20.0 v 17:42Z.
• scripts/ci-plan vybírá celou shellovou sadu pro změnu záznamu a grep případů, které čtou metadata release, jich najde 41, 8202 sekund, jeden z nich sám 35 až 58 minut. Užší verdikt pro záznam také nemůže být krátký.

Vlastník stanovil limit 15 minut od tagu po obsluhovaný release a rozhodl, na dotaz 2026-10-10, že běh release publikuje svá metadata sám, než přistane záznam.

Rozhodnutí

1. Release publikuje vlastní metadata. Publikační úloha po odvození záznamu a všech jeho projekcí a po jejich posouzení přes scripts/derive-check spustí scripts/site-deploy --release-metadata <tag>. Zkopíruje site/static/releases/<tag>.json a site/static/releases/latest.json z onoho stromu na to, co obsluhuje gh-pages, commitne je samostatně a pushne. Je to tentýž deploy skript s jedním dalším režimem, ne druhá cesta nasazení.

2. Dva soubory a nic jiného. build.json, každá stránka a každý další soubor zůstávají tím, co publikoval poslední deploy masteru. Kontrola pages-live, která požaduje, aby byl web sestaven z commitu na masteru, stále čte commit masteru.

3. Režim odmítne to, za co nemůže ručit. Značka, jejíž soubor chybí, latest.json, který jmenuje jinou značku nebo se liší od souboru značky, vzdálený repozitář bez gh-pages a release starší než ten, který poskytuje gh-pages, se odmítnou s návratovým kódem 10 a nic se nepushne.

4. Web se nikdy nevrací o release zpět. Mezi publikací metadat a přistáním záznamu nese každý deploy masteru latest.json předchozího release. Běžný deploy proto zachová releases/latest.json, které gh-pages servíruje, a soubor tagu, který jmenuje, když jmenuje verzi novější než build, to uvede na svém výstupu a jmenuje ho v commit zprávě gh-pages. Jakmile build jmenuje stejnou nebo novější verzi, nezachová se nic. Verze se porovnávají číselně pole po poli; nečitelná strana nezachovává nic.

5. Záznam stále přistává pod plným verdiktem. Jeho pull request se navrhuje jako dřív a merguje se, když projde jeho ci. Mění se jen to, že na něj nikdo nečeká s instalací releasu.

Důsledky

Od tagu k servírovaným metadatům je plán, nejpomalejší sestavení a úloha publikace: 28 až 31 minut ve dvou změřených bězích, z nichž krok package na macOS x86_64 je 866 sekund a úloha publikace znovu odvozuje strom, který právě odvodila (271 sekund), a znovu sestavuje spustitelný soubor, který už sestavily úlohy sestavení (117 sekund). Patnáct minut, které vlastník stanovil, samotné toto rozhodnutí nedosáhne; vyžadují zkrácení i sestavení a úlohy publikace, o čemž se zde nerozhoduje.

Po dobu mezi publikací a přistáním záznamu web servíruje metadata, která nejsou na masteru. Jsou projekcí publikovaného záznamu, posuzovanou kontrolou odvození stromu, který ji navrhuje, a jeho archivy už jsou na GitHub Releases; pull request záznamu pak dostane stejné bajty na master. Záznam, který nikdy nepřistane, nechá web servírovat release, který master nezaznamenává, a release-check tento stav jmenuje stejně, jako jmenoval okna v0.19.1 a v0.20.0.

Úloha smoke, která čeká, až latest.json jmenuje release, už nečeká, až člověk zmerguje záznam.

Zamítnuté alternativy

• Zmergovat záznam na užším verdiktu. Změřeno výše: mezi případy, které čtou metadata release, je jeden, který běží většinu hodiny.
• Při každém release mergovat záznam s právy administrátora. Pokaždé to obchází ochranu větve a v0.20.0 k tomu potřeboval člověka.
• Nasadit celý web ze stromu záznamu. build.json by jmenoval commit, který není na masteru, kontrola pages-live by ho odmítla a další nasazení masteru by ho stejně nahradilo.
• Nechat metadata přepsat dalším nasazením masteru. Web by několik minut obsluhoval nový release a po dalším merge zase starý: instalátor by během jednoho odpoledne vydával dvě verze.