Этот блог поддерживается Пеликан и размещается через GitHub с использованием Страницы GitHub. В этом посте я опишу рабочий процесс, который я использую при развертывании новых постов.

Для тех из вас, кто не знаком с этими технологиями, Pelican — это генератор статических сайтов, что означает, что вы можете писать свой контент в таком формате, как Уценка, и Pelican автоматически сгенерирует для вас HTML-файлы; и GitHub Pages — это услуга, предоставляемая GitHub для размещения веб-сайта под URL-адресом .github.io.

Использовать Pelican и GitHub Pages довольно просто. Однако есть одна досадная мелочь… GitHub Pages предполагает, что master ветка содержит корневую папку, которая будет предоставлена ​​миру. Если вы используете настройки Pelican по умолчанию, output
папка — это папка, которую вы хотите обслуживать. output содержит сгенерированные файлы веб-сайта. Естественным выбором того, как организовать файлы внутри репозитория, было бы определение корневой папки pelican — родителя output – как корень репозитория. Но GitHub Pages нужно
output быть корнем. Облом…

Есть те
которые решают эту проблему, используя два отдельных репозитория: один для «исходных» файлов веб-сайта, а другой — для вывода, который будет обслуживаться с помощью GitHub Pages.

Лично мне не нравится разбивать мой блог на два репозитория. Я хочу хранить все в одном месте, поэтому решил решить проблему с помощью веток и git-хуков.

Первым шагом является создание двух веток:

• source будут содержать “исходные” файлы блога, а именно – все файлы, такие как content папка, которая содержит фактические сообщения, и pelicanconf.py файл.
• master будет содержать только содержимое output.

Эти ветки, очевидно, будут жить в моем репозитории GitHub Pages (https://github.com/yoel-zeldes/yoel-zeldes.github.io), а поскольку master ветвь содержит outputсодержимое, пользователь, перешедший на yoel-zeldes.github.io, увидит все достоинства моего блога.

К сожалению, ручное обслуживание этих двух ветвей обременительно. Git Hooks спешит на помощь!

В Git есть механизм для выполнения пользовательских скриптов при выполнении определенных важных действий. В моем случае всякий раз, когда я нажимаю коммит на source филиал, я хотел бы master ветке, чтобы получать обновления с новым содержимым output. Это можно сделать с помощью хука pre-push, который выполняется, как вы уже догадались, непосредственно перед отправкой.

Все, что вам нужно сделать, это создать файл с именем .git/hooks/pre-push со следующим содержанием:

#!/bin/sh
while read local_ref local_sha remote_ref remote_sha
do
        if ( "$remote_ref" = "refs/heads/source" )
        then
                echo 'pushing output folder (production version) to master...'
                pelican content -o output -s publishconf.py
                echo anotherdatum.com > output/CNAME
                ghp-import output
                git push --no-verify git@github.com:yoel-zeldes/yoel-zeldes.github.io.git gh-pages:master
                pelican content -o output
        fi
done

exit 0

1. Первое, что делает скрипт, — перебирает коммиты, которые должны быть отправлены. В частности, только коммиты, которые
   source отрасли нас интересуют.
2. Если коммиты нажимаются на sourceон выполняет pelican команда с использованием publishconf.py. Это создаст производственную версию блога в output.
3. Затем он создает CNAME файл, который необходим, поскольку я использую собственный домен (http://anotherdatum.com).
4. Импорт страниц GitHub инструмент используется для копирования содержимого output в филиал под названием gh-pages.
5. gh-pages выталкивается на удаленный master ветвь. --no-verify пропускает хук pre-push, чтобы этот скрипт больше не запускался.
6. pelican выполняется снова, чтобы создать версию моего блога для разработки, чтобы я мог написать следующий пост.

Теперь, всякий раз, когда я нажимаю на sourceи только к source, master обновляется с новым содержимым. Прохладный!

И последняя маленькая деталь: я добавил output к .gitignore файл. Таким образом, source ветка не будет включать эту папку. На самом деле мы не хотим помещать его под контроль версий — это было бы похоже на помещение других типов сгенерированных файлов, таких как
.pyc или .o под контролем версий.