Před prvním nasazením

Někdo stěhuje blog z WordPressu na blog.sh a nechává si stejný hosting, stejný adresář i stejnou adresu. Sestavení je hotové, první nasazení projde bez jediné chyby – a úvodní stránka je pořád ta stará. Při nahrávání se nic nepokazilo. Starý web jen nikdo neodstranil a hosting mu dává přednost.

Nasazení maže jen to, co samo zapsalo

Nasazení zapíše soubory webu a smaže jen ty, které tam dalo některé předchozí nasazení téhož webu. Všechno ostatní v cíli zůstává, a to záměrně: engine nemá jak poznat, jestli je soubor, který nezapsal, pozůstatek, nebo něco, co potřebuješ, a nasazení, které by se jednou spletlo, by už nikdo nepovažoval za spolehlivé.

To pravidlo je správné a má jeden ostrý důsledek. Většina sdílených hostingů obslouží index.php dřív než index.html, takže v kořeni dál odpovídá stará úvodní stránka WordPressu, zatímco nový index.html leží hned vedle a nikdo ho nevidí. Starý .htaccess může dál přepisovat adresy, na kterých nový web závisí. Nahrání se podařilo, jen se k němu čtenář nedostane. (Výjimkou je backend git – každý push nahradí celou větev, takže tam nic starého nepřežije.)

Nejdřív se zeptej cíle

doctor --online přečte kořen cíle nasazení a vyjmenuje všechno, co tam tenhle web nedává:

$ ./blog.sh doctor --online
⚠️  V kořeni cíle nasazení (/var/www/mujblog) leží položky, které tam tento web nedává (položek: 5): .htaccess, google1234abcd.html, index.php, wp-content/, wp-login.php.
   Mezi nimi je index.php, a hosting ho obslouží dřív než index.html — stará úvodní stránka tak může dál zakrývat novou. Nasazení nikdy nemaže, co samo nenahrálo, takže tyhle položky zůstanou a servírují se vedle webu. Co nechceš, smaž ručně (FTP, správce souborů hostingu); co tam je záměrně, vypiš v config/site.yml pod deploy.keep a doctor to přestane hlásit (.well-known, kde hosting drží ověření certifikátu, nehlásí nikdy).

Funguje stejně u všech backendů – Surfer přes jeho API, místní adresář přečtením, rsync, rclone a sftp výpisem adresáře – jedním dotazem a s časovým limitem, takže hosting, který neodpovídá, je varování, ne zamrznutí. Spusť ho, jakmile je cíl nastavený v env.sh, a dřív, než se cokoli nahraje.

Ukliď a nech, co má zůstat

Úklid je na tobě, s tím, čím jsi spravoval starý web: FTP klientem nebo správcem souborů hostingu. Nech, co tam dal hosting sám. .well-known/, kde hosting drží ověření certifikátu, se ve výpisu vůbec neobjeví.

Něco tam ale leží záměrně – ověřovací soubor pro vyhledávač nebo snímky obrazovky, na které pořád odkazuje staré hlášení. Ty vypiš pod deploy.keep v config/site.yml:

deploy:
  keep:
    - google1234abcd.html

a příští běh už o nich mlčí:

✅ Cíl nasazení (/var/www/mujblog) odpovídá a všechno v jeho kořeni patří tomuto webu.

Ten seznam čte jen doctor. Nasazení nemaže, co samo nezapsalo, tak jako tak, takže keep je poznámka pro doctora, ne zámek na cíli.

Program za backendem

Čtyři ze šesti backendů předávají nahrávání programu – rsync, rclone, sftp, git – a stroj, na kterém chyběl, se to dřív dozvěděl až při prvním nasazení, když už proběhlo celé sestavení. Teď se ptá doctor:

❌ Backend rsync spouští rsync a ten tu není nainstalovaný — každé nasazení by po sestavení selhalo.
   Nainstaluj rsync z balíčků systému a pak znovu spusť ./blog.sh doctor.

rclone má vlastní past. Když je nainstalovaný jako snap, smí číst jen v tvém domovském adresáři, takže web uložený v /srv selže při každém nasazení na souborech, které tam prokazatelně jsou. doctor pojmenuje i tohle a místo snapu doporučí balíček z distribuce nebo rclone.org.

A nenastavuj ho předčasně

Ještě jedna věc stojí za to, než cíl zapíšeš do env.sh: uložení konceptu web sestaví a nasadí, protože náhled konceptu je skutečná adresa na skutečném webu. První nasazení tak málokdy spouštíš ručně. Neupravený env.sh nenasazuje nikam a všechno ostatní funguje – psaní, náhled, import – takže cíl může počkat, až bude web připravený k prohlížení a až se doctor --online podívá, co už tam leží.