Два начина за разполагане на публичен сайт на GitHub Pages от частно хранилище на Hugo

Дръжте вашите чернови далеч от очите на обществеността, като използвате инструменти за непрекъснато внедряване, за да публикувате своя публичен сайт на GitHub Pages - от отделно частно хранилище.

Инструменти като Travis CI и Netlify предлагат някои доста изящни функции, като безпроблемно разгръщане на вашия сайт на GitHub Pages, когато промените се изпращат към неговото хранилище. Заедно със статичния генератор на сайтове като Hugo, поддържането на актуален блог е доста безболезнено.

Използвах Hugo за изграждането на моя сайт от години, но до последната седмица никога не бях свързвал хранилището на своите страници с нито една услуга за внедряване. Защо? Тъй като използването на инструмент, който е изградил моя сайт преди разгръщане, изглежда е изисквало цялата рецепта да бъде на едно място - и ако използвате GitHub Pages с безплатната версия на GitHub, това място е публично. Това означава, че всичките ми ярки идеи от три сутринта и разхвърляните недовършени (и нелепи) чернови ще бъдат публично достъпни - и никакво непрекъснато удобство нямаше да ме убеди да го направя.

Затова държах нещата разделени, с разхвърляните неща от задкулисието на Hugo в локално хранилище на Git и генерираната public/папка, бутаща към моето отдалечено хранилище GitHub Pages. Всеки път, когато исках да разположа сайта си, трябваше да се кача на лаптопа си и hugoда изградя сайта си, след това cd public/ && git add . && git commit... и т.н. И т.н. И всичко беше добре, с изключение на неприятното усещане, че има по-добър начин да направя това.

Малко по-късно написах друга статия за използването на GitHub и Working Copy, за да правя промени в хранилищата си на iPad, когато съм навън. Струваше ми се, че мога да направя всичко, освен да разположа сайта си от моя iPad, затова се заех да го променя.

Няколко ярки идеи три сутринта и отменен маркер за достъп по-късно (ами сега), сега имам не един, а два начина за разполагане в публичното ми хранилище на GitHub Pages от изцяло отделено, частно хранилище на GitHub. В този пост ще ви преведа да постигнете това с Травис CI или да използвате Netlify и Make.

В това няма нищо хакерско - публичното ми хранилище на GitHub Pages все още изглежда същото, както изглежда, когато го натиснах локално от моя терминал. Едва сега мога да се възползвам от няколко чудесни инструмента за внедряване, за да актуализирам сайта, когато натисна частното си репо, независимо дали съм на лаптопа си или навън с моя iPad.

Тази статия предполага, че имате познания за страниците Git и GitHub. Ако не, може да искате да отделите някои раздели на браузъра от моите статии за използването на GitHub и Работно копиране и първо да създадете сайт с Hugo и GitHub Pages.

Хайде да го направим!

Частно-публично внедряване на GitHub Pages с Travis CI

Травис CI има вградената способност (♪) да се разположи в GitHub Pages след успешно изграждане. Те вършат прилична работа в документите, като обясняват как да добавите тази функция, особено ако сте използвали Travis CI преди ... което аз не съм. Не се притеснявайте, аз направих по-голямата част от измислянето за вас.

  • Travis CI получава всички свои инструкции от конфигурационен файл в корен на вашето хранилище, наречен .travis.yml
  • Трябва да предоставите маркер за личен достъп на GitHub като защитена криптирана променлива, която можете да генерирате с помощта travisна командния ред
  • След като вашият скрипт завърши успешно да прави това, което сте му казали (не е задължително това, което искате да направи, но това е съвсем друга публикация в блога), Травис ще разположи вашата директория за изграждане в хранилище, което можете да посочите с repoпроменливата на конфигурацията.

Настройване на конфигурационния файл на Травис

Създайте нов конфигурационен файл за Травис с името на файла .travis.yml(обърнете внимание на водещото „.“). Тези скриптове са много адаптивни и аз се мъчих да намеря подходящ пример, който да използвам като отправна точка - за щастие, нямате този проблем!

Ето моето основно .travis.yml:

git: depth: false env: global: - HUGO_VERSION="0.54.0" matrix: - YOUR_ENCRYPTED_VARIABLE install: - wget -q //github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz - tar xf hugo_${HUGO_VERSION}_Linux-64bit.tar.gz - mv hugo ~/bin/ script: - hugo --gc --minify deploy: provider: pages skip-cleanup: true github-token: $GITHUB_TOKEN keep-history: true local-dir: public repo: gh-username/gh-username.github.io target-branch: master verbose: true on: branch: master

Този скрипт изтегля и инсталира Hugo, изгражда сайта със събирането на боклука и минимизира флаговете, след което разполага public/директорията до посоченото repo- в този пример вашето публично хранилище на GitHub Pages. Можете да прочетете за всяка от deployопциите за конфигуриране тук.

За да добавите маркера за личен достъп на GitHub като криптирана променлива, не е необходимо да редактирате ръчно своя .travis.yml. На travisкоманди скъпоценни долу ще шифроват и добавяне на променливата за вас, когато ги пуснете в хранилище директория.

Първо инсталирайте travisс sudo gem install travis.

След това генерирайте своя GitHub персонален маркер за достъп, копирайте го (той се показва само веднъж!) И изпълнете командите по-долу в корена на хранилището, замествайки вашия маркер за целувките:

travis login --pro --github-token xxxxxxxxxxxxxxxxxxxxxxxxxxx travis encrypt GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxx --add env.matrix

Вашият криптиран маркер магически се появява във файла. След като се ангажирате .travis.ymlс вашето частно хранилище на Hugo, Travis CI ще стартира скрипта и ако компилацията успее, ще разположи вашия сайт в публичното ви репо GitHub Pages. Магия!

Травис винаги ще изпълнява компилация всеки път, когато натиснете вашето частно хранилище. Ако не искате да задействате това поведение с определен ангажимент, добавете skipкомандата към вашето съобщение за фиксиране.

Йо, това е страхотно, но харесвам Netlify.

Добре добре.

Внедряване в отделно хранилище с Netlify и Make

Можем да накараме Netlify да оферира с помощта на Makefile, който ще стартираме с командата за изграждане на Netlify.

Ето как Makefileизглежда нашият :

SHELL:=/bin/bash BASEDIR=$(CURDIR) OUTPUTDIR=public .PHONY: all all: clean get_repository build deploy .PHONY: clean clean: @echo "Removing public directory" rm -rf $(BASEDIR)/$(OUTPUTDIR) .PHONY: get_repository get_repository: @echo "Getting public repository" git clone //github.com/gh-username/gh-username.github.io.git public .PHONY: build build: @echo "Generating site" hugo --gc --minify .PHONY: deploy deploy: @echo "Preparing commit" @cd $(OUTPUTDIR) \ && git config user.email "[email protected]" \ && git config user.name "Your Name" \ && git add . \ && git status \ && git commit -m "Deploy via Makefile" \ && git push -f -q //$(GITHUB_TOKEN)@github.com/gh-username/gh-username.github.io.git master @echo "Pushed to remote"

За да запазим историята на Git на отделното ни хранилище на GitHub Pages, първо ще го клонираме, ще изградим новия ни сайт Hugo към него и след това ще го върнем обратно в хранилището Pages. Този скрипт първо премахва всяка съществуваща public/папка, която може да съдържа файлове или история на Git. След това клонира нашето хранилище на страници public/, изгражда нашия сайт Hugo (по същество актуализира файловете в public/), след което се грижи за ангажирането на новия сайт в хранилището на страниците.

В deployраздела ще забележите редове, започващи с &&. Това са верижни команди. Тъй като Make извиква нова под-черупка за всеки ред, тя започва отначало с всеки нов ред от нашата основна директория. За да накараме нашите cdда се придържат и да избегнем изпълнението на нашите Git команди в основната директория на проекта, ние веригираме командите и използваме обратната наклонена черта, за да прекъснем дългите редове за четливост.

Чрез веригиране на нашите команди ние можем да конфигурираме нашата Git идентичност, да добавим всички наши актуализирани файлове и да създадем фиксиране за нашето хранилище на страници.

Подобно на използването на Travis CI, ще трябва да предадем токен за личен достъп на GitHub, за да го изпратим в публичното ни хранилище на GitHub Pages - само Netlify не предоставя ясен начин за криптиране на маркера в нашия Makefile.

Вместо това ще използваме променливите на среда на изграждане на Netlify, които живеят безопасно в настройките на сайта ни в приложението Netlify. След това можем да извикаме нашата символна променлива в Makefile. Използваме го, за да избутаме (тихо, за да избегнем отпечатването на маркера в регистрационни файлове) към нашето хранилище на страници, като го предадем в отдалечения URL адрес.

За да избегнем отпечатването на маркера в регистрационните файлове на Netlify, ние потискаме отзвук на рецепта за този ред с водещия @знак.

С вашия Makefile в корена на вашето частно хранилище на GitHub, можете да настроите Netlify да го стартира вместо вас.

Настройване на Netlify

Настройването на Netlify чрез уеб потребителския интерфейс е лесно. След като влезете с GitHub, изберете частното хранилище на GitHub, където живее вашият сайт Hugo. Следващата страница, която Netlify ви отвежда, ви позволява да въведете настройки за разполагане:

Можете да посочите командата за изграждане, която ще стартира вашия Makefile ( make allза този пример). Клонът за разполагане и директорията за публикуване не са от особено значение в нашия конкретен случай, тъй като се занимаваме само с натискане към отделно хранилище. Можете да въведете типичния masterклон за разполагане и да publicпубликувате директория.

Под „Разширени настройки за изграждане“ щракнете върху „Нова променлива“, за да добавите своя маркер за личен достъп на GitHub като променлива на среда на изграждане. В нашия пример името на променливата е GITHUB_TOKEN. Щракнете върху „Deploy site“, за да осъществите магията.

Ако вече сте настроили хранилището си с Netlify, намерете настройките за Непрекъснато внедряване под Настройки> Изграждане и внедряване.

Netlify ще изгради вашия сайт всеки път, когато натиснете частното хранилище. Ако не искате конкретен ангажимент да задейства компилация, добавете [skip ci]съобщението си за ангажиране в Git.

Едни и същи, но различни

Единият ефект от използването на Netlify по този начин е, че вашият сайт ще бъде изграден на две места: едното е отделното публично хранилище на GitHub Pages, към което се изпраща Makefile, а другото е вашият сайт на Netlify, който се разгръща на своя CDN от вашия частен GitHub хранилище. Последното е полезно, ако ще играете с Deploy Previews и други функции на Netlify, но те са извън обхвата на тази публикация.

Основното е, че вашият сайт на GitHub Pages е актуализиран в публичния ви репо. Ех!

Вървете и се разположете безстрашно

Надявам се, че ефектът от тази нова информация е, че се чувствате по-способни да актуализирате сайтовете си, където и да се намирате. Възможностите са безкрайни - у дома на дивана с лаптопа си, навън в кафенето с iPad или в средата на първата среща на телефона ви. Безкраен!