Обзор того, когда использовать действия контейнера Docker вместо действий JavaScript в GitHub, и подробное описание того, как их создать.

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

Я рассмотрел два типа действий: действия JavaScript и действия контейнера Docker. Многие действия с открытым исходным кодом, которые я исследовал, созданы с использованием действий Javascript - возможно, по следующим причинам:

  1. Они могут использовать удобный инструментарий GitHub, который предоставляет библиотекам доступ к входам действий и клиенту GitHub, который можно настроить с помощью токена.
  2. Все GitHub Runner прямо из коробки поддерживают Node 12, что позволяет очень просто писать действия на основе этой версии Node. Никакой дополнительной настройки не требуется. Чтобы узнать, какое программное обеспечение поддерживается в средах GitHub Runner, загляните в документацию.

Когда бы вы использовали действие контейнера Docker?

Действие контейнера Docker проявляется в некоторых случаях.

При использовании JavaScript не вариант

  • Возможно, ваша команда знакома с другими языками или фреймворками.
  • Может быть, вы предпочитаете, чтобы все ваши инструменты были единообразными. Возможно, вы напишете все свои инструменты на Go и захотите продолжать это делать.
  • Возможно, вы хотите использовать утилиту или библиотеку, которых нет в Node. Например, скрипт Python для обработки или анализа данных, которые ваша команда уже написала и которые вы не хотите переносить на JavaScript.

Когда вы поете конкретную версию Node (12), это не вариант

Возможно, вы захотите основать свое действие на другой версии Node.

Даже если вы используете поддерживаемую версию Node 12 для создания своего действия, вам все равно может быть полезно использовать действие контейнера Docker по нескольким причинам:

  1. Вам больше не нужно включать папку node_modules непосредственно в репозиторий действий. У вас может быть package.json файл, в котором перечисляются зависимости, и ваш контейнер Docker вытаскивает зависимости вниз при запуске действия.
  2. Объединение среды, необходимой для запуска действия, с самим действием, предотвратит возможные критические изменения во время обновления программного обеспечения для среды выполнения GitHub.

Создание действия контейнера Docker

В поисках интересных действий для создания я наткнулся на это действие в StoryBook GitHub organization, которое еще не было полностью проработано!

Это действие, предназначенное для создания и развертывания сайта Storybook на страницах GitHub Pages или в корзине AWS S3. В этой статье я расскажу, как создать действие контейнера GitHub Docker для этого варианта использования.

Для ознакомления с действиями контейнера Docker, привет, ознакомьтесь с документацией GitHub.

Определение действия

Сначала мы определяем интерфейс действия - его входы, выходы и его среду - в файле action.yml в корне репозитория:

Входы в действие

Мы указываем следующие входные данные для GitHub Action:

  1. access-token: токен персонального доступа GitHub, необходимый для отправки в определенную ветку репозитория.
  2. branch: целевая ветка, в которой нужно развернуть сайт Storybook.

Образ Docker для действия

Действия контейнера Docker определяют образ, используемый для запуска контейнера, в котором выполняется код действия. Для действий Docker мы указываем действие для запуска с помощью docker. image можно указать одним из двух способов:

1. Используя Dockerfile в репозитории действия:

Это то, что мы использовали в нашем примере.

2. Используя образ из общедоступного реестра Docker:

Передача входных данных в контейнер Docker

В идеале мне хотелось бы, чтобы входные данные, указанные для действия Docker, автоматически передавались в контейнер Docker при его запуске. Однако для этого нужен дополнительный шаг. args укажите аргументы, передаваемые в контейнер Docker, когда средство выполнения задания выполняет действие.

Исполнитель задания передает аргументы ENTRYPOINT контейнера при запуске контейнера.

Создание Dockerfile

Мы следуем стандартному синтаксису и принципам написания файлов Docker с некоторыми оговорками, специфичными для реализации GitHub, изложенными в документации.

Dockerfile для этого действия использует alpine Linux в качестве основы для образа, добавляет узел и Git и указывает Docker запускать entrypoint.sh, когда контейнер начинает использовать этот образ.

Средство запуска GitHub создаст образ из нашего Dockerfile, запустит контейнер, используя этот образ, и запустит код в entrypoint.sh при запуске контейнера.

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

Некоторые важные из них:

  1. --workdir /github/workspace: он устанавливает рабочий каталог контейнера в рабочую область бегуна (где в этом случае предполагается, что репозиторий был клонирован). Этот каталог также передается как переменная среды GITHUB_WORKSPACE.
  2. args, указанные в action.yml, передаются в качестве последних аргументов:
  • Deborah-Digges:***: запутанный токен GitHub
  • gh-pages: ветка в репозитории для отправки

Запуск кода в контейнере!

Мы указали, что наш ENTRYPOINT является сценарием bash, и мы можем запускать сценарий узла, модуль Python или почти все, что захотим!

В этом случае вместо написания кода для создания и продвижения сайта Storybook на страницы GitHub мы будем использовать Storybook-deployer. Простите за обман! Он не завершен, потому что, как видите, он предполагает множество вещей о проекте (например, тот факт, что он использует npm, а не yarn).

Вот шаги для развертывания сайта сборника рассказов:

  1. Установите зависимость storybook-deployer.
  2. Запустите storybook-deployer с правильными аргументами ветки и токена.

Ознакомьтесь с кодом выполненного действия на GitHub.

Использование действия контейнера Docker в рабочем процессе GitHub

Давайте посмотрим, как мы можем использовать это действие в репозитории, который использует Storybook для создания и развертывания сайта Storybook в gh-pages ветке GitHub при каждом нажатии на master.

Нам нужно создать файл рабочего процесса в репозитории, расположенном по адресу .github/workflows:

Мы указываем, что хотим, чтобы этот рабочий процесс запускался при каждом нажатии на ветку master. Этот рабочий процесс состоит из одного задания под названием build, которое состоит из трех этапов:

  1. Проверьте репозиторий с помощью действия actions/checkout@v2.
  2. Установите зависимости, запустив сценарий.
  3. Разверните сайт Storybook на страницах GitHub, используя только что созданное действие.

Мы ссылаемся на действие, используя синтаксис deborah-digges/[email protected], который включает:

  1. Владелец или название организации
  2. Имя репозитория
  3. Версия, которая может быть тегом или идентификатором фиксации в репозитории.

Чтобы увидеть этот рабочий процесс в действии (без каламбура), ознакомьтесь с этим репозиторием, в котором используется действие, которое мы только что создали для развертывания сайта Storybook на GitHub Pages.

Вы даже не видели действия GitHub?

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

Чтобы лучше понять это, важно помнить, что этапом рабочего процесса может быть:

  1. Действие, которое инкапсулирует некоторую логику, вызываемую с использованием требуемых входных данных.
  2. Команда bash запускается в самом рабочем процессе.

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

Изменение файла рабочего процесса для запуска кода действия в файле рабочего процесса выполняет ту же работу без необходимости создавать и поддерживать новый репозиторий действий!

Вопрос, на который мы действительно должны ответить, прежде чем приступить к написанию отдельного действия GitHub: «Получат ли другие пользу от этой абстракции?»

Если ответ отрицательный, нам, вероятно, не нужно писать новое действие GitHub.

Заключение

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

Если вы хотите быстро освежить в памяти, что такое GitHub Actions, почему они полезны или как написать действие JavaScript, ознакомьтесь с моей предыдущей статьей.