Два способи розгортання загальнодоступного сайту GitHub Pages із приватного сховища Hugo

Тримайте свої чернетки поза увагою громадськості, використовуючи інструменти постійного розгортання для публікації вашого загальнодоступного сайту GitHub Pages - з окремого приватного сховища.

Такі інструменти, як Travis CI та Netlify, пропонують деякі досить чудові функції, такі як плавне розгортання вашого веб-сайту GitHub Pages, коли зміни надсилаються до його сховища. Поряд із статичним генератором веб-сайтів, таким як Гюго, постійно оновлювати свій блог досить безболісно.

Я багато років використовував Hugo для створення свого сайту, але до минулого тижня я ніколи не підключав сховище своїх сторінок до жодної служби розгортання. Чому? Оскільки для використання інструменту, який створив мій сайт до розгортання, здавалося, потрібно було мати весь рецепт в одному місці - і якщо ви використовуєте сторінки GitHub із безкоштовною версією GitHub, це місце є загальнодоступним. Це означає, що всі мої яскраві ідеї три ранку та безладні незавершені (і невтішні) чернетки будуть загальнодоступними - і жодна безперервна зручність не збиралася переконати мене це зробити.

Тож я тримав речі окремо, безладні закулісні речі Гюго у локальному сховищі Git, а створена public/папка надсилалася до мого віддаленого сховища GitHub Pages. Кожного разу, коли я хотів розгорнути свій сайт, мені доводилося сідати на ноутбук і hugoбудувати свій сайт, потім cd public/ && git add . && git commit... і т. Д. І все було добре, за винятком настирливого відчуття, що є кращий спосіб зробити це.

Я написав ще одну статтю про те, як використовувати GitHub і Working Copy для внесення змін до моїх сховищ на iPad, коли б я не працював. Мені здалося, що я можу робити все, крім розгортання свого сайту зі свого iPad, тому я вирішив це змінити.

Кілька яскравих ідей три ранку та пізніше відкликаний маркер доступу (ой), тепер у мене є не один, а два способи розгортання у моєму загальнодоступному сховищі сторінок GitHub із повністю відокремленого приватного сховища GitHub. У цій публікації я розповім вам про те, як досягти цього за допомогою Тревіса CI або за допомогою Netlify and Make.

У цьому немає нічого хакерського - моє загальнодоступне сховище сторінок GitHub все ще виглядає так само, як і коли я натискав на нього локально зі свого терміналу. Тільки зараз я можу скористатися кількома чудовими інструментами розгортання, щоб оновлювати сайт кожного разу, коли я переходжу до свого приватного репо, незалежно від того, перебуваю я на своєму ноутбуці чи поза ним, і з iPad.

Ця стаття передбачає, що ви добре знаєте сторінки Git та GitHub. Якщо ні, то, можливо, вам сподобається виділити деякі вкладки браузера з моїх статей про використання GitHub та Working Copy та спочатку побудувати сайт на сторінках Hugo та GitHub.

Давайте зробимо це!

Розгортання приватних загальнодоступних сторінок GitHub за допомогою Тревіса Сі

Travis CI має вбудовану здатність (♪) розгортатися на сторінках GitHub після успішної збірки. Вони роблять гідну роботу в документах, пояснюючи, як додати цю функцію, особливо якщо ви раніше використовували Travis CI ... чого у мене немає. Не хвилюйтесь, я зробив для вас основну частину роздумів.

  • Всі інструкції Travis CI отримує із конфігураційного файлу у кореневій частині вашого сховища .travis.yml
  • Вам потрібно надати маркер особистого доступу GitHub як захищену зашифровану змінну, яку ви можете генерувати за travisдопомогою командного рядка
  • Після того, як ваш скрипт успішно закінчить виконувати те, що ви йому наказали (не обов'язково те, що ви хочете , але це ціла інша публікація в блозі), Тревіс розгорне ваш каталог побудови у сховищі, яке ви можете вказати за допомогою repoзмінної конфігурації.

Налаштування файлу конфігурації Travis

Створіть новий файл конфігурації для Тревіса з назвою файлу .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. Про кожен з deployваріантів конфігурації ви можете прочитати тут.

Щоб додати маркер особистого доступу GitHub як зашифровану змінну, вам не потрібно вручну редагувати свій .travis.yml. Наведені travisнижче команди gem будуть шифрувати та додавати змінну для вас, коли ви запускаєте їх у своєму каталозі сховища.

Спочатку встановіть за 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 build.

Ось як 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, ми спочатку клонуємо його, побудуємо до нього наш новий сайт Hugo, а потім повернемо назад до сховища Pages. Цей сценарій спочатку видаляє будь-яку існуючу public/папку, яка може містити файли або історію Git. Потім він клонує наш репозиторій Pages public/, створює наш сайт Hugo (по суті, оновлюючи файли в public/), а потім бере на себе записування нового сайту до сховища Pages.

У цьому deployрозділі ви помітите рядки, що починаються з &&. Це ланцюгові команди. Оскільки Make викликає нову допоміжну оболонку для кожного рядка, вона починається спочатку з кожного нового рядка з нашого кореневого каталогу. Для того, cdщоб наші команди залишались на місці та не запускали наші команди Git у кореневому каталозі проекту, ми створюємо ланцюжки команд і використовуємо символ зворотної риски для розриву довгих рядків для читабельності.

Зв’язуючи наші команди, ми можемо налаштувати свою ідентичність Git, додати всі оновлені файли та створити коміт для нашого сховища Сторінок.

Подібно до використання Travis CI, нам потрібно буде передати маркер персонального доступу GitHub, щоб перейти до нашого загальнодоступного сховища Сторінок GitHub - лише Netlify не надає простого способу шифрування маркера в нашому Makefile.

Натомість ми будемо використовувати змінні середовища побудови Netlify, які безпечно живуть у налаштуваннях нашого сайту в додатку Netlify. Потім ми можемо викликати нашу змінну маркера в Makefile. Ми використовуємо його для проштовхування (тихо, щоб уникнути друку маркера в журналах) до нашого сховища Сторінок, передаючи його у віддалену URL-адресу.

Щоб уникнути друку маркера в журналах Netlify, ми припиняємо відлуння рецептів для цього рядка з провідним @символом.

За допомогою Makefile в корені вашого приватного сховища GitHub, ви можете налаштувати Netlify для запуску його для вас.

Налаштування Netlify

Налаштування Netlify через веб-інтерфейс є простим. Після входу в систему за допомогою GitHub виберіть приватне сховище GitHub, де живе ваш сайт Hugo. Наступна сторінка, з якою Netlify переходить, дозволяє ввести налаштування розгортання:

Ви можете вказати команду build, яка запускатиме ваш файл Makefile ( make allдля цього прикладу). Гілка для розгортання та каталог публікацій не мають великого значення в нашому конкретному випадку, оскільки ми маємо справу лише з переходом до окремого сховища. Ви можете ввести типову masterгілку розгортання та publicопублікувати каталог.

У розділі «Додаткові налаштування збірки» натисніть «Нова змінна», щоб додати свій маркер особистого доступу GitHub як змінну середовища побудови. У нашому прикладі ім'я змінної GITHUB_TOKEN. Натисніть «Розгорнути сайт», щоб здійснити магію.

Якщо ви вже налаштували свій репозиторій за допомогою Netlify, знайдіть налаштування для Безперервного розгортання в розділі Налаштування> Створення та розгортання.

Netlify will build your site each time you push to the private repository. If you don’t want a particular commit to trigger a build, add [skip ci] in your Git commit message.

Same same but different

One effect of using Netlify this way is that your site will be built in two places: one is the separate, public GitHub Pages repository that the Makefile pushes to, and the other is your Netlify site that deploys on their CDN from your linked private GitHub repository. The latter is useful if you’re going to play with Deploy Previews and other Netlify features, but those are outside the scope of this post.

The main point is that your GitHub Pages site is now updated in your public repo. Yay!

Go forth and deploy fearlessly

I hope the effect of this new information is that you feel more able to update your sites, wherever you happen to be. The possibilities are endless — at home on your couch with your laptop, out cafe-hopping with your iPad, or in the middle of a first date on your phone. Endless!