Кэширование, совместное использование и отладка рабочих процессов

  • 8 мин

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

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

  • Кэширование зависимостей для более быстрых рабочих процессов.
  • Передача данных артефактов между заданиями.
  • Включите ведение журнала отладки для рабочих процессов.
  • Доступ к журналам рабочих процессов из пользовательского интерфейса GitHub и REST API.
  • Используйте маркеры установки для проверки подлинности приложений GitHub.

Кэширование зависимостей с помощью действия кэша

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

Чтобы кэшировать зависимости для задания, используйте действие GitHub cache . Это действие извлекает кэш, определенный уникальным ключом, который вы задаете. Когда действие находит кэш, оно извлекает кэшированные файлы в настроенный путь. Чтобы использовать cache действие, необходимо задать несколько определенных параметров:

Параметр Описание Обязательно
Key Ссылается на идентификатор ключа, созданный при сохранении и поиске кэша. Да
Path Указывает путь к файлу в средстве выполнения для кэширования или поиска. Да
Restore-keys Состоит из альтернативных существующих ключей для кэширования, если нужный ключ кэша не найден. нет 
steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

В предыдущем примере для path задано значение ~/.npm, а key включает операционную систему средства выполнения и хэш SHA-256 файла package-lock.json. Префикс ключа с идентификатором (npm-cache в этом примере) полезен при использовании резервного restore-keys копирования и нескольких кэшей.

Передача данных артефактов между заданиями

Аналогично идее кэширования зависимостей в рабочем процессе, можно передавать данные между заданиями внутри одного рабочего процесса. Передача данных может быть выполнена с помощью действий upload-artifact и download-artifact. Задания, зависящие от артефактов предыдущего задания, должны ждать успешного завершения предыдущего задания, прежде чем они смогут запуститься. Этот подход полезен, если у вас есть ряд заданий, которые должны выполняться последовательно на основе артефактов, отправленных из предыдущего задания. Например, job_2 требует job_1 путем использования синтаксиса needs: job_1.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

В этом примере есть две работы. job_1 записывает некоторый текст в файл file.txt. Затем он использует actions/upload-artifact@v2 действие для отправки этого артефакта и хранения данных для дальнейшего использования в рабочем процессе. job_2 требуется job_1 выполнить выполнение с помощью синтаксиса needs: job_1 . Затем оно использует actions/download-artifact@v2 действие для скачивания этого артефакта, а затем печати содержимого file.txt.

Включение ведения журнала отладки шагов в рабочем процессе

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

  • Чтобы включить ведение журнала диагностики, установите ACTIONS_RUNNER_DEBUG секрет в репозитории true, содержащем рабочий процесс.
  • Чтобы включить ведение журнала диагностики шагов, установите секрет ACTIONS_STEP_DEBUG в репозитории, содержащем рабочий процесс на true.

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

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

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

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

  1. В репозитории перейдите на вкладку "Действия ".
  2. В левой области выберите рабочий процесс.
  3. В списке запусков рабочего процесса выберите запуск.
  4. В разделе "Задания" выберите задание.
  5. Прочтите содержимое журнала.

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

Доступ к журналам рабочих процессов из REST API

Помимо просмотра журналов с помощью GitHub, можно использовать REST API GitHub для просмотра журналов выполнения рабочих процессов, повторного запуска рабочих процессов или даже отмены выполнения рабочих процессов. Чтобы просмотреть журнал выполнения рабочего процесса с помощью API, отправьте GET запрос в конечную точку журналов. Помните, что любой пользователь с доступом на чтение к репозиторию может использовать эту конечную точку. Если репозиторий является частным, необходимо использовать маркер доступа с областью repo.

Например, GET запрос на просмотр определенного журнала выполнения рабочего процесса следует этому пути:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Определение того, когда следует использовать маркер установки из приложения GitHub

Когда приложение GitHub установлено на учетной записи, его можно аутентифицировать как установку приложения, используя installation access token для запросов API REST и GraphQL. Этот шаг позволяет приложению получить доступ к ресурсам, принадлежащим установке, при условии, что приложению предоставлен необходимый доступ к репозиторию и разрешения. Запросы REST или GraphQL API, сделанные установкой приложения, относятся к приложению.

В следующем примере вы замените INSTALLATION_ACCESS_TOKEN на маркер доступа для установки.

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

Вы также можете использовать маркер доступа к установке для проверки подлинности для доступа Git на основе HTTP. Приложение должно иметь разрешение на репозиторий Contents . Затем можно использовать маркер доступа к установке в качестве пароля HTTP.

TOKEN Замените в примере маркером доступа к установке:

git clone https://x-access-token:TOKEN@github.com/owner/repo.git