při merge do masteru se spustí build na Travis CI, který vždy projde (nic netestuje) a nasadí novou verzi
deploy.py
deploy.py vygeneruje html do _build složky, přepíše jejím obsahem lokální gh-pages větev (nástrojem ghp-import) a pak ji pushne na github
pokud deploy.py zjistí, že je na Travis CI, tak předtím ještě nastaví git - jako autora deploy commitu nastaví autora posledního commitu v masteru a do origin URL přidá GITHUB_TOKEN, který vyčte z environmentu (je zašifrovaný utilitkou travis encrypt a uložený v .travis.yml, utilitka se nainstaluje gem install travis, token se získá na https://github.com/settings/tokens a stačí public_repo práva... travis encrypt se musi delat v adresari s repozitarem webu, vysledna sifrovacka je totiz specificka pro repo), aby mohl pak dělat push zpátky na github
(do commitu do gh-pages se přidá náhodný smajlík, aby šlo aspoň pohledem do gh-pages branche na githubu vidět, jestli je to jiný commit než minule, hodí se to občas na ladění deploy mechanismu a navíc je to taková hezká malá srandička :smile: :wink: )
github zaregistruje změnu v gh-pages větvi a nasadí novou verzi webu
je potřeba .nojekyll file, jinak se github zblázní (vidí totiž sphinxové _static aj. adresáře) a myslí si, že ve větvi je Jekyll blog
je potřeba CNAME soubor, kde je napsána kanonická doména
je potřeba mít reálně doménu nasměrovanou na githubí dnska podle jejich dokumentace
Poznámky:
_build
složky, přepíše jejím obsahem lokální gh-pages větev (nástrojem ghp-import) a pak ji pushne na githubtravis encrypt
a uložený v .travis.yml, utilitka se nainstaluje gem install travis, token se získá na https://github.com/settings/tokens a stačípublic_repo
práva...travis encrypt
se musi delat v adresari s repozitarem webu, vysledna sifrovacka je totiz specificka pro repo), aby mohl pak dělat push zpátky na github_static
aj. adresáře) a myslí si, že ve větvi je Jekyll blogMělo by se to lidsky sepsat do README nebo někam.