Развертывание 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 из своего проекта. Теперь мне не придется повторно решать одну и ту же задачу.


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

Добавить ответ:
Отменить.