Как использовать GitHub Actions для создания рабочих процессов для CI?

Завершено

Здесь вы узнаете о действиях и рабочих процессах GitHub для CI.

Вы узнаете, как:

• Создание рабочего процесса из шаблона
• Общие сведения о журналах GitHub Actions
• Тестирование с несколькими целевыми объектами
• Отдельные задания сборки и тестирования
• Сохранение и доступ к артефактам сборки
• Автоматизация маркировки PR во время проверки

Создание рабочего процесса из шаблона

Чтобы создать рабочий процесс, начните с шаблона. Шаблон содержит общие задания и шаги, предварительно настроенные для конкретного типа автоматизации, которую вы реализуете. Если вы не знакомы с рабочими процессами, заданиями и шагами, ознакомьтесь с Автоматизация задач разработки с помощью модуля GitHub Actions.

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

На странице "Выбор рабочего процесса" вы можете выбрать из множества различных шаблонов. Одним из примеров является шаблон Node.js, который выполняет чистую установку зависимостей узлов, создает исходный код и выполняет тесты для разных версий Node. Другим примером является шаблон пакета Python, который устанавливает зависимости Python и выполняет тесты, включая lint, в разных версиях Python.

В поле поиска введите Node.js.

В результатах поиска в области Node.js выберите Настроить.

Этот рабочий процесс шаблона по умолчанию Node.js отображается в только что созданном файле node.js.yml.

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Обратите внимание на атрибут on:. Этот рабочий процесс активируется при отправке изменений в репозиторий и при создании pull request против основной ветви.

В этом рабочем процессе есть один job. Давайте рассмотрим, что это делает.

Атрибут runs-on: указывает, что для операционной системы рабочий процесс выполняется на ubuntu-latest. Атрибут node-version: указывает, что существует три сборки, по одному для Node версии 14.x, 16.x и 18.x. Мы описываем часть matrix подробно позже, при настройке рабочего процесса.

steps в задании используется действие GitHub Actions actions/checkout@v3, чтобы получить код из вашего репозитория на виртуальную машину, а также действие actions/setup-node@v3, чтобы настроить правильную версию Node.js. Мы указываем, что мы собираемся протестировать три версии Node.js с помощью атрибута ${{ matrix.node-version }}. Этот атрибут ссылается на матрицу, которая была определена ранее. Атрибут cache указывает диспетчер пакетов для кэширования в каталоге по умолчанию.

Последняя часть этого шага выполняет команды, используемые проектами Node.js. Команда npm ci устанавливает зависимости из файла package-lock.json, npm run build --if-present запускает скрипт сборки, если он существует, и npm test запускает платформу тестирования. Обратите внимание, что этот шаблон включает как этапы сборки, так и тестовые действия в одном задании.

Дополнительные сведения о npm см. в документации по npm:

• npm install
• npm run
• тест npm

Журналы действий для сборки

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

Если ошибка или сбой теста, в журналах отображается красный ✖, а не зеленый флажок ✔. Вы можете изучить сведения об ошибке или сбое, чтобы изучить то, что произошло.

В упражнении вы определите неудачные тесты, проверив подробные сведения в журналах. Журналы можно получить на вкладке "Действия".

Настройка шаблонов рабочих процессов

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

Давайте рассмотрим, как настроить рабочий процесс.

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16.x, 18.x]

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

Четыре сборки, а также все их тесты, создают довольно много логов. Это может быть сложно разобраться во всём этом. В следующем примере показано, как переместить шаг теста в выделенное тестовое задание. Это задание тестирует несколько целевых объектов. Разделение шагов сборки и тестирования упрощает понимание журнала.

test:
  runs-on: ${{ matrix.os }}
  strategy:
    matrix:
      os: [ubuntu-latest, windows-latest]
      node-version: [16.x, 18.x]
  steps:
  - uses: actions/checkout@v3
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - name: npm install, and test
    run: |
      npm install
      npm test
    env:
      CI: true

Что такое артефакты?

Когда рабочий процесс создает что-то, отличное от записи журнала, продукт называется артефактом. Например, сборка Node.js создает контейнер Docker, который можно развернуть. Данный артефакт, то есть контейнер, может быть загружен в хранилище с помощью действия actions/upload-artifact, а затем скачан из хранилища с помощью действия actions/download-artifact.

Сохранение артефакта обеспечивает его сохранность между заданиями. Каждое задание использует свежий экземпляр виртуальной машины, поэтому вы не можете повторно использовать артефакт, сохраняя его на виртуальной машине. Если вам нужен артефакт в другом задании, вы можете передать артефакт в хранилище в одном задании и скачать его для другого задания.

Хранилище артефактов

Артефакты хранятся в хранилище на GitHub. Пространство свободно для общедоступных репозиториев, и некоторые суммы бесплатны для частных репозиториев, в зависимости от учетной записи. GitHub хранит артефакты в течение 90 дней.

В следующем фрагменте рабочего процесса обратите внимание, что в действии actions/upload-artifact@main есть атрибут path:. Значением этого атрибута является путь для хранения артефакта. Здесь мы указываем public/, чтобы загрузить все в каталог. Если нам просто нужно загрузить один файл, мы используем что-то вроде public/mytext.txt.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

Чтобы скачать артефакт для тестирования, сборка должна успешно завершиться и артефакт должен быть загружен. В следующем коде мы указываем, что тестовое задание зависит от задания сборки.

test:
    needs: build
    runs-on: ubuntu-latest

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

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

Дополнительные сведения об использовании артефактов в рабочих процессах см. в разделе Хранение данных рабочего процесса в виде артефактов в документации по GitHub.

Автоматизация проверок в GitHub с помощью рабочих процессов

До сих пор мы описали запуск рабочего процесса с событиями GitHub, такими как push или pull request. Можно также запустить рабочий процесс по расписанию или на некоторых событиях за пределами GitHub.

Иногда мы хотим запустить рабочий процесс только после того, как пользователь выполняет действие. Например, мы хотим запустить рабочий процесс только после того, как рецензент утвердит запрос на вытягивание. В этом сценарии можно активировать pull-request-review.

Еще одним действием, которое можно предпринять, является добавление метки к запросу на слияние. В этом случае мы используем действие pullreminders/label-when-approved-action.

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

Обратите внимание, что блок называется env:. Этот блок определяет переменные среды для этого действия. Например, можно задать необходимое количество утверждающих. Вот один. Переменная аутентификации secrets.GITHUB_TOKEN необходима, поскольку действие должно внести изменения в ваш репозиторий, добавляя метку. Наконец, укажите имя добавляемой метки.

Добавление метки может быть событием, которое запускает другой рабочий процесс, например слияние. Мы осветим эту тему в следующем модуле по вопросу непрерывной доставки с помощью GitHub Actions.