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

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

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

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

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

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

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

• Ограниченная публичная бета-версия была анонсирована в 2018 году на конференции GitHub Universe. 
• Полноценная бета была анонсирована в августе 2019 с поддержкой CI/CD, пользовательских событий и предполагаемых рабочих потоков.
• Полноценная версия стала доступна с ноября 2019 года.
• В сентябре 2020 была запущена бета GitHub Enterprise.

Почему GitHub Actions?

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

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

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

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

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

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

Когда я активировала на панели настроек 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.

• Затем я поискала на маркетплейсе GitHub Actions подходящий экшен для развертывания Gatsby-сайта на GitHub Pages.

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

name: Gatsby Publish

on:
  push:
    branches:
      master

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: enriikke/gatsby-gh-pages-action@v2
        with:
          access-token: ${{ secrets.ACCESS_TOKEN }}
          deploy-branch: gh-pages

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

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

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

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

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

Читайте также:

• 10 популярных проектов GitHub, написанных на Python
• GitHub Codespaces: быстрая разработка на ходу с Flutter
• Kubernetes: безопасное управление секретами с GitOps

Читайте нас в Telegram, VK и Яндекс.Дзен

---

Перевод статьи Deborah Digges: Deploy Your Gatsby Site With GitHub Actions