Управление рабочими процессами и отладка в GitHub Actions

10 мин

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

Чтобы реализовать этот процесс, вы узнаете, как:

Определите событие, активировающее рабочий процесс.
Используйте журналы рабочих процессов GitHub Actions.
Сохранение и доступ к артефактам сборки.
Автоматизируйте добавление метки в pull request после проверки.

Определение события, активировающего рабочий процесс

Понимание того, что активировал рабочий процесс GitHub Actions, имеет решающее значение для отладки, аудита и улучшения конвейеров CI/CD. Тип триггеров включает push в ветку, создание или обновление пулл-реквеста, запланированное задание или ручную отправку. Можно определить инициирующее событие, проверив выполнение рабочего процесса, изменения репозитория и связанную проблему в GitHub или пулл-реквест.

Схема, показывающая различные триггеры рабочего процесса в GitHub Actions, например push-запрос, запрос на вытягивание, расписание и отправку вручную.

Что такое триггер рабочего процесса?

Триггер рабочего процесса — это событие, которое приводит к выполнению рабочего процесса. GitHub поддерживает различные типы триггеров, в том числе:

push или pull_request (на основе изменений кода)
workflow_dispatch (ручной триггер)
schedule (задания cron)
repository_dispatch (внешние системы)
События, связанные с проблемами, обсуждениями и пул-реквестами (например, issues.opened, pull_request.closed)

Определение события триггера

Событие триггера рабочего процесса можно определить несколькими способами:

Используйте пользовательский интерфейс GitHub Actions:
1. В репозитории выберите вкладку "Действия ".
2. Выберите запуск рабочего процесса.
Тип события, например pushpull_request, или workflow_dispatch, отображается в верхней части сводки по выполнению рабочего процесса.
Используйте github.event_name в журналах или в рабочем процессе.
- GitHub предоставляет данные контекста во время выполнения рабочего процесса. Переменная github.event_name сообщает, какое событие активировало рабочий процесс.
- Вы можете распечатать сведения на шаге для отладки:
```
-name: Show event trigger
  run: echo "Triggered by ${{ github.event_name }}"
```
Используйте сведения о выполнении рабочего процесса:
- При программном выполнении рабочего процесса, например с помощью API, объект запуска содержит event свойство, указывающее триггер.
- Вы можете найти коммит Secure Hash Algorithm (SHA), участника и метку времени для отслеживания того, что вызвало триггер.

Определить триггер на основе эффектов репозитория

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

Наблюдаемое поведение	Событие триггера
В `main` был отправлен новый коммит и рабочий процесс запущен.	событие `push`
Запрос pull request был открыт или обновлен.	событие `pull_request`
Участник вручную выполнил рабочий процесс.	`workflow_dispatch`
Рабочий процесс выполняется ежедневно в определенное время.	`schedule` (крoн)
Рабочий процесс выполнялся после вызова внешней службы.	`repository_dispatch`
Рабочий процесс выполняется при добавлении метки или комментария к проблеме.	событие `issues.*`

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

Чтобы определить, что активировало рабочий процесс, выполните следующие действия.

Проверьте сводку по выполнению рабочего процесса на вкладке "Действия ".
Распечатайте или зарегистрируйте github.event_name в рабочем процессе для обеспечения видимости.
Сравните метки времени и активность в репозитории (коммиты, запросы на вытягивание, вопросы), чтобы вывести триггер.
Используйте полный event контекст для более глубокого изучения.

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

Понимание эффекта рабочего процесса через чтение его файла конфигурации

Чтобы понять влияние рабочего процесса на чтение файла конфигурации, проанализируйте структуру и содержимое файла, сохраненного .yml в .github/workflows/.

Файл конфигурации рабочего процесса указывает следующие сведения о рабочем процессе:

При запуске (в on разделе).
Что это делает (в jobs и steps).
Где он выполняется ( runs-on раздел).
Почему выполняется программа (ее назначение, например тестирование, развертывание или линтинг).
Поведение в определенных условиях (среда, фильтры, логика).

Интерпретация эффекта рабочего процесса

Определите триггер.

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

Рассмотрим пример.
```
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:
```
В этом примере рабочего процесса:
- Выполняется автоматически при отправке кода в основную ветвь (push).
- Выполняется при создании или обновлении пулл-реквеста (pull_request).
- Можно активировать вручную пользователем (workflow_dispatch).
Определите задания и шаги рабочего процесса.

Сведения о том, что делает рабочий процесс, см. в jobssteps разделах рабочего процесса.

Рассмотрим пример.
```
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
```
В этом примере рабочего процесса:
- Использует виртуальную среду Linux (runs-on).
- Извлекает код репозитория (steps>name).
- Устанавливает зависимости проекта (steps>name).
- Выполняет автоматические тесты (steps>name).
Оцените цель и результат рабочего процесса.

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

"Этот рабочий процесс является конвейером непрерывной интеграции (CI). Это гарантирует, что любой новый код, отправленный в репозиторий или предъявленный через pull запрос, автоматически проверяется. Если тесты завершаются сбоем, пользовательский интерфейс рабочего процесса GitHub отображает этот результат, чтобы обеспечить качество кода".
Определите или задайте необязательные функции, влияющие на выполнение рабочего процесса:
- env задает переменные среды.
- if добавляет условную логику для выполнения определенных шагов только в том случае, если выполнены критерии.
- timeout-minutes или continue-on-error задайте выполнение рабочего процесса и обработку ошибок.

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

В репозитории перейдите на вкладку "Действия ".
Найдите неудачный запуск (обычно обозначается красным X).
Выберите неудачный рабочий процесс, чтобы открыть сводку выполнения.
В журналах рабочих процессов просмотрите ошибку.
1. В сводке по выполнению разверните каждое задание и шаг, пока не найдете тот, который указывает на сбой.
2. Выберите задание или шаг, чтобы просмотреть журналы.
3. Найдите:
  - Сообщения об ошибках
  - Трассировки стека
  - Коды выхода
Например, неудачный тест может показать npm ERR! Test failed или exit code 1.
Проверьте файл конфигурации рабочего процесса.

Используйте файл .yml для определения:
- Что пытается сделать каждый шаг?
- Если существуют переменные среды (env) или условные (if), влияющие на выполнение.
- Если сбой возникает из-за отсутствия зависимостей, синтаксической ошибки или неправильно настроенного шага.
Если шаг завершается ошибкой, проверьте следующие причины:
- Были ли зависимости установлены успешно на предыдущем шаге?
- Существуют ли тестовые файлы и передаются локально?

Распространенные сценарии сбоев

В следующей таблице описаны распространенные сценарии сбоя рабочего процесса:

Симптом	Вероятно, причина
Шаг завершается сбоем и возвращает `command not found`l	Отсутствие зависимостей или неправильной настройки
`npm install` не работает.	Проблема с поврежденным `package-lock.json` файлом или сетью
Сбой тестового шага	Проблемы модульного теста, отсутствующий файл конфигурации или недопустимый синтаксис теста
появится `Permission denied`.	Неверные разрешения на файл или отсутствующие секреты

Определение доступа к журналам рабочих процессов в GitHub

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

Например, если файл .yml содержит следующий код, в списке появится ссылка с заголовком CI Workflow :
```
name: CI Workflow
```
Выберите конкретный запуск.

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

На странице сводки запуска отображаются задания, определенные в файле рабочего процесса, например сборка или проверка:
1. Выберите задание, чтобы развернуть его.
2. В рамках задания разверните отдельные шаги, такие как "Установите зависимости" или "Запустите тесты".
Просмотр выходных данных журнала.

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

В следующей таблице приведены инструкции по доступу к журналам рабочих процессов.

Действие	Цель
Вкладка "Действия"	Просмотр всех запусков рабочего процесса.
Выберите имя рабочего процесса	Фильтрация выполняется по рабочему процессу.
Выбор запуска	Посмотрите результаты конкретных задач и шагов.
Этапы развертывания	Просмотр подробных журналов.
Скачивание журналов	Скачайте журналы для автономного или командного устранения неполадок.

Логи операций для сборки

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

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

Снимок экрана: журнал GitHub Actions с подробными сведениями о неудачном тесте.

Работа с артефактами

Когда рабочий процесс создает что-то, отличное от записи журнала, продукт называется артефактом. Например, сборка 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, например 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.

Обратная связь

Были ли сведения на этой странице полезными?