Nasadit web ručně

Účel

Dostat web živě hned, ne po frontě Actions, aniž by vznikl druhý způsob publikace. Jeden příkaz, ten samý, který spouští workflow Pages, a nasazení je poté vidět: commit gh-pages i patička webu uvádějí zdrojový commit.

Kdy použít

Operátor to řekne, slovy, v této relaci. Merge do masteru už nasazuje přes workflow; ruční nasazení je pro případy, kdy je to příliš pomalé, nebo je workflow červené z důvodu, který není web (benchmark runner, job pro macOS), a web sám je zelený. Nikdy nenasazujte proto, aby červená kontrola vypadala zeleně.

Postup

1. Předpoklady

• Stojíte na commitu k publikaci, s čistým stromem, a origin/master jej obsahuje. Náhled nesloučené práce je možný pomocí --any-ref; patička pak jmenuje onen commit, takže si ho nikdo nespletl s masterem. Řekněte to, když to děláte.
• zola, node_modules (npm ci) a pro plnou kontrolu cargo jsou přítomny; skript říká, co přeskakuje.
• GitHub Pages poskytuje větev gh-pages. Jednou na repozitář: scripts/site-deploy --configure-pages (vyžaduje gh); poté nastavení zůstává.

2. Nasazení

scripts/site-deploy --dry-run      # gate, build, check; shows the gh-pages commit it would push
scripts/site-deploy                # the same, then pushes gh-pages
scripts/site-deploy --probe        # add the browser probe (every route at 320, 390, 1280 px)

just site-deploy je tentýž příkaz. Kontrola je: odvozená data synchronní, generované projekce synchronní (majordomus generate --check), site-build, site-check. Selhání kdekoli zastaví před pushem, s důvodem; opravte zdroj, nikdy výstup.

Build webu neskládá snapshot UI (ADR 0141): workflow pages jej zapisuje v samostatném jobu a jeho deploy job jej umístí. Deploy z terminálu takový job nemá, takže skript odmítne postavený web, kterému chybí snapshot, jejž model publikace deklaruje (scripts/pages snapshots je vypisuje), nebo který nese snapshot přečtený při jiném commitu, a vypíše příkazy, které jej umístí (project.the-published-ui-is-the-trunks). Po tomto odmítnutí je web už postaven a zkontrolován, proto zapište snapshot při tomto commitu, zkopírujte jej na jeho mount a publikujte, co tam je:

majordomus web report ui-snapshot
mkdir -p site/public/ui && cp -R target/web/ui-snapshot/. site/public/ui/
scripts/site-deploy --skip-build

3. Ověřte

GitHub servíruje novou hlavu branche za zhruba minutu. Nasazení je skutečné, když živý web pojmenovává commit, který jste publikovali:

curl -s https://majordomus.dev/ | grep -c "/commit/$(git rev-parse HEAD)"   # 1

scripts/pages verify-ui --commit "$(git rev-parse HEAD)" se totéž ptá UI na /ui/: jeho snímek pojmenovává tento commit a odpovídá každá stránka, kterou vypisuje.

Pak otevřete stránku, kterou jste změnili.

Pro čtení z druhé strany — díváš se na živý web a chceš vědět, co to je — git log -1 --format='%an %s' origin/gh-pages pojmenuje zdrojový commit a řekne, kdo jej publikoval: github-actions[bot] pro push do masteru, člověk pro ruční nasazení. Náhled publikovaný přes --any-ref zůstává živý, dokud jej další push do masteru nepřepíše, takže živý web, který není master, je očekávaný, ne chybný.

4. Nedělejte

• Cokoli pod site/public/ nebo na gh-pages upravovat ručně: obojí jsou výstupy. Chybná stránka se opraví ve svém zdroji a znovu nasadí.
• Nasadit ze špinavého stromu s --allow-dirty, „jen se podívat“: patička by jmenovala commit, který neobsahuje to, co je živé.
• Obejít odmítnutou kontrolu. Řádky REFUSE jsou důvody, proč by nasazení uvádělo v omyl; skript skončí s kódem 10 a nic nepushne.

Výstup

Commit, který je nyní živý, pojmenovaný, a větev, do níž byl pushnut; nebo, když kontrola odmítla, řádek REFUSE, který ho zastavil, a zdroj, který je třeba opravit. Zaznamenejte deploy tam, kde úloha drží své poznámky (majordomus checkpoint), se zdrojovým commitem, aby se na to, co je živé, dalo později odpovědět bez dotazu na GitHub.