Развертывание Gatsby-сайта с помощью GitHub Actions



Книга Развертывание Gatsby-сайта с помощью GitHub Actions

Вот уже несколько недель, как я знакомлюсь с Gatsby. Пока что я перенесла на него свой старый блог с Jekyll и создала конвейер, непрерывно развертывающий его на Github Pages. Для создания конвейера CD я использовала Travis CI


GitHub Actions. Знакомство…


Команда GitHub вкладывает немало усилий в расширение платформы для комплексной поддержки рабочих процессов репозиториев.


“GitHub Actions  —  это ваш рабочий поток: организованный вами, реализуемый нами.”  —  блог GitHub


Это означает, что вместо того, чтобы выполнять собственные сборки на внешнем CI вроде Travis, все те же возможности теперь можно получить и на GitHub.


Экшены как функционал были внедрены два года назад, и с тех пор команда GitHub постоянно этот функционал дорабатывает, опираясь на отзывы сообщества:



Почему GitHub Actions?


У меня был идеально работающий CD конвейер в Travis CI. В чем же проблема? 


Еще одна ссылка в цепочке, которая могла дать сбой, еще один сторонний инструмент, состояние которого необходимо отслеживать, еще одна строка в счете за использование SaaS, еще один сервис, через который перетекают мои данные и о котором необходимо сообщить группе по контролю соответствия. В общем, вы поняли. 


При этом весьма забавно, что когда я пыталась настроить Travis CI для своего блога, то сервис заявлял о снижении производительности. Я даже подумала, что сама чего-то не понимаю, потому что несколько раз кряду не смогла заставить его работать. 


Сообщение о проблемах производительности Travis CI

GitHub Actions избавляют от подобных неприятных сюрпризов:


  • Исключается внедрение стороннего инструмента и пересылка данных через дополнительный сервис. 
  • Предлагается более доступная тарифная сетка, чем при использовании отдельного сервиса для CI/CD. Публичные репозитории обслуживаются бесплатно, а частные платят по мере пользования услугами.
  • Есть возможность задействовать общие рабочие потоки. Этот пункт особенно важен, так как избавляет разработчиков от необходимости раз за разом решать одни и те же задачи. Вместо этого общедоступными потоками формируется экосистема экшенов, которые во многом аналогично коду можно ответвлять, редактировать, повторять и совершенствовать.

Принцип работы сборки на Travis CI


Активация сборок в репозитории на travis-ci.org

Когда я активировала на панели настроек Travis CI выполнение сборок в репозитории GitHub, то сервис настроил в нем соответствующий вебхук:


 Travis CI вебхук в настройках репозитория GitHub

Согласно этой настройке генерируемые в репозитории события передавались управляемому Travis CI вебхуку, который запускал сборку на основе этапов, определенных в моем файле .travis.yml.


Запуск сборки Travis CI с помощью GitHub Action


Такой подход, по сути, немногим улучшает рабочий поток, поскольку только изменяет точку интеграции между GitHub и Travis CI.


Вместо вебхука, прослушивающего события GitHub, экшен Travis-CI GitHub для запуска сборки на Travis CI в ответ на событие GitHub задействует API Travis CI v3 .


Зависимость сохраняется  —  а с ней и ее проблемы. 


Развертывание GitHub Pages с помощью GitHub Action (Прощай, Travis)


В итоге я начала искать экшен GitHub, который мог бы выполнять те же функции, что конвейер сборки и развертывания на Travis CI: запускать сборку, выполнять ряд пока нет существующих тестов и отправлять сгенерированный сайт в ветку gh-pages репозитория.


В ходе недолгих поисков я без труда нашла разработанный сообществом экшен как раз для этой цели, с которым и интегрировала свой репозиторий: 


  • Первым делом я отключила сборку Travis CI в настройках, деактивировав тем самым соответствующий вебхук на GitHub.

Сборки на travis-ci.org 

Отключенный вебхук Travis Ci в репозитории


Экшен Gatsby Publish

  • Далее вручную добавила этот экшен в файл YAML репозитория по адресу .github/workflows. Этот шаг меня несколько расстроил, так как я рассчитывала, что смогу закоммитить файл рабочего потока в репозиторий за один клик.

name: Gatsby Publish

on:
push:
branches:
master

jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/[email protected]
- uses: enriikke/[email protected]
with:
access-token: ${{ secrets.ACCESS_TOKEN }}
deploy-branch: gh-pages

  • Чтобы рабочий поток мог совершать отправку в репозиторий, я установила в качестве переменной среды ACCESS_TOKEN раздела Secrets репозитория токен GitHub.

Раздел Secrets в настройках репозитория

  • Разобравшись со всем этим, я смогла активировать первую сборку, выполнив слияние с мастер-веткой репозитория.

Процесс выполнения сборки

Полученные преимущества


Даже при таком небольшом проекте я добилась с помощью GitHub Actions некоторых преимуществ:


  • Процесс сборки блога больше не зависит от Travis CI. Я смогла отключить репозиторий от этого сервиса и удалила там свой аккаунт. 
  • Мне удалось повторно использовать общий рабочий поток, разработанный сообществом, и удалить код, связанный с развертывание GitHub Pages из своего проекта. Теперь мне не придется повторно решать одну и ту же задачу.



674   0  

Comments

    Ничего не найдено.