Pull to refresh

Comments 14

Это самописный Action который:
— работает на JS, а идея была использовать только свой язык программирования и bash(это в том числе описано в моменте где уточнение про выбор генератором — Pelican);
— речь идет об отправке файлов в репозиторий (то же что наши три команды для чистого git), тогда как это можно сделать не тащя за собой node и npm, и еще некоторые пользовательские пакеты к node.

Если говорить про джекил, то он в гитхабе включён по умолчанию и так и норовит упасть, запоров вам деплой, о чём вы узнаете только письмом счастья на почту. Чтобы этого не происходило нужно добавить в корень ветки пустой .nojekyll файл.

Хорошое уточнение!

Но учитывая что все файлы в конечном репозитории будут чистыми .html, такое поведение маловероятно.

И если в них встретятся двойные фигурные скобочки, то джекил упадёт.

Действительно, touch .nojekyll выглядит как хорошая идея.


В пакет добавлю этот момент.

Ну и такие инструкции по сборке лучше не в виде статей поставлять, а в виде собственно github action. сделать это совсем не сложно. Например, сборку МАМ проектов я вынес в экшен https://github.com/hyoo-ru/mam_build ввиду чего настройка деплоя очередного проекта крайне упростиласть.

Ну почему же, одно другому не мешает. Статья полезная и внимания привлечёт больше, а ссылку на готовый репозиторий можно в конец добавить

Интересная и полезная статья, спасибо! Как раз вчера думал на эту тему, а тут — хопа! — и готовое решение подъехало. Строго говоря, через подобную автоматизацию можно наворотить много чего: форматирование кода, разного рода автофиксы, сохранение контекста автотестов и т.п. Механизм во всех случаях один и тот же

Это был рассмотрен наиболее близкий для меня юзкейс.

Во время написания статьи углубился в эту тему и очень вдохновлен возможностями лежащим на поверхности (про подобные Docker, разные Travis и прочие CI/CD я знаю, но с этим не выходя из GitHub выглядит перспективнее для малых проектов), теперь останется только придумать куда это применять.
У меня все так же почти, но сделано на CircleCI и Hugo (golang) (учитывая, что синтаксис там везде на yml, портировать при необходимости — раз плюнуть). Отличие разве что в том, что у меня два языка на сайте, а github позволяет только один домен на репозиторий, пришлось сделать схему из 4 репозиториев (по факту 3, но тему оформления решил вынести отдельно). Workflow получился вот такой — github.com/Alroniks/source-klimchuk/blob/master/.circleci/config.yml
Сначала сборка и тестирование билда, а потом уже деплой.
Отдельное спасибо за реализацию коммита, только если есть изменения. Подсмотрел и реализовал сегодня, а до этого просто пушил с форсом каждый раз заново.

Полезная статья, но как то все очень сложно сделано. Предпочел в разы проще взял lektor + простая публикация на гитлаб (который можно было на гитхаб заменить).

А почему именно Pelican? А не Hugo или Hexo или Gatsby?

Sign up to leave a comment.

Articles