Web se nasazuje jedním skriptem, scripts/site-deploy, z terminálu nebo z publikačního workflow; odmítne špinavý strom, commit, který master neobsahuje, a build, který není z HEAD, pushne site/public do gh-pages s uvedením zdrojového commitu a nepushne nic, když je výstup beze změny

Co to znamená

scripts/site-deploy je jediný způsob, jakým se web dostane na GitHub Pages. Workflow Pages ho spouští po své kontrole; člověk ho spouští, když operátor chce web živě bez čekání na frontu Actions (.ai/repo/skills/deploy-site/SKILL.md, just site-deploy). Tak či onak běží stejné kontroly a pushuje se stejná větev: gh-pages, kterou obsluhuje GitHub Pages.

Princip

Skript odmítne (exit 10, nic se nepushne) pracovní strom s necommitnutými změnami, HEAD, který origin/master neobsahuje (--any-ref publikuje náhled a řekne to), a site/public, jehož patička neuvádí HEAD. Pokud není zadáno --skip-build, spustí kontrolu: scripts/generate-site-data --check, majordomus generate --check je-li přítomen cargo, scripts/site-build, scripts/site-check a sondu v prohlížeči s --probe. Poté zkopíruje site/public do worktree gh-pages (vytvořeného jako orphan, pokud branch neexistuje), přidá .nojekyll, commitne se zdrojovým commitem a otiskem registru ve zprávě a pushne. Nezměněný výstup se znovu necommituje; --dry-run ukáže commit, který by pushnul. --configure-pages nasměruje GitHub Pages na branch jednorázově prostřednictvím gh.

Jak to vidět

scripts/site-deploy --dry-run       # gate, build, check; "would push <sha> to origin/gh-pages: deploy: site from <source>"
scripts/site-deploy                 # the same, then the push; GitHub serves it in about a minute
curl -s https://majordomus.dev/ | grep -c "/commit/$(git rev-parse HEAD)"   # 1
git log -1 --format='%an %s' origin/gh-pages    # github-actions[bot] for a workflow deploy, a person for a hand one

Co nepokrývá

Náhled se publikuje, nezabrání se mu. --any-ref existuje proto, aby bylo možné nesloučenou práci prohlédnout na skutečném hostiteli, takže po něm je živý web commitem, který origin/master neobsahuje, a zůstane takový, dokud jej nepřepíše další push na master. To je zamýšlená životnost, ne únik: patička stránky uvádí commit, ze kterého byla sestavena, zpráva commitu gh-pages říká deploy: site from <sha> a jeho autorem je člověk, který skript spustil, ne github-actions[bot], takže to, co je publikováno, lze vždy vyčíst z webu samotného. Čtení patičky nebo toho commitu je způsob, jak odlišit náhled od masteru, a obojí je rychlejší než porovnávání tras.

Skript nerozhoduje, kdy nasazovat; rozhoduje operátor a workflow při každém pushi do masteru. Nečiní červenou kontrolu zelenou: neúspěšná kontrola zastaví před pushem. Neservíruje web sám; to dělá vlastní „pages build and deployment“ GitHubu a tento krok je GitHubu.

Proč existuje

Dvě cesty nasazení, jedna pro CI a jedna pro člověka, by byla dvě místa, kde se kontrola může rozejít, a z gh-pages by nešlo poznat, odkud stránka pochází. test/cases/96_site_deploy.sh naklonuje checkout, dá mu lokální bare remote, sestaví web a dokládá, že každé odmítnutí nepushne nic, první nasazení vytvoří gh-pages s webem, .nojekyll a zdrojovým commitem ve zprávě, opětovné nasazení nezměněného výstupu nepushne nic a site/public sestavený z jiného commitu je odmítnut.