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

  • 9 мин

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

Узнайте следующие темы:

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

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

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

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

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

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

Screenshot showing GitHub Actions tab with the search box highlighted and containing the text 'Node.js'.

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

Screenshot showing GitHub Actions tab with the Node.js pane highlighted and the Node.js template selected.

Этот рабочий процесс шаблона по умолчанию 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:. Этот рабочий процесс активируется при отправке в репозиторий и когда запрос на вытягивание выполняется в основной ветви.

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

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

В steps задании используется действие GitHub Actions/проверка out@v3 для получения кода из репозитория на виртуальную машину, а также действия или действия установки 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:

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

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

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

GitHub Actions log with details on a failed test.

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

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

В начале этого модуля мы описали сценарий, в котором необходимо настроить 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, который можно развернуть. Этот артефакт, контейнер, можно передать в хранилище с помощью действия действия или артефакта upload-artifact и последующего скачивания из хранилища с помощью действий или артефакта download-artifact.

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

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

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

В следующем фрагменте рабочего процесса обратите внимание, что в actions/upload-artifact@main действии есть path: атрибут. Значением этого атрибута является путь для хранения артефакта. Здесь мы указываем 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, такими как отправка или запрос на вытягивание. Можно также запустить рабочий процесс по расписанию или на некоторых событиях за пределами 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.