Настройка рабочего процесса с помощью переменных среды и данных артефактов

  • 12 мин

В этом уроке вы научитесь применять переменные сред (пользовательские и по умолчанию), пользовательские скрипты, зависимости кэша и передачу данных артефактов между заданиями. Вы также узнаете, как получить доступ к журналам рабочих процессов, как с веб-сайта GitHub, так и с конечных точек REST API.

Переменные среды по умолчанию и контексты

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

jobs:
  prod-check:
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

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

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

В этом примере используется контекст github.ref для проверки ветви, вызвавшей рабочий процесс. Если ветвь — main, то запускается средство выполнения и выводится "Развертывание на рабочий сервер в ветви $GITHUB _REF". Переменная среды по умолчанию $GITHUB_REF используется в средстве выполнения для ссылки на ветвь. Обратите внимание, что все переменные среды по умолчанию пишутся прописными буквами, а переменные контекста — строчными.

Пользовательские переменные среды

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

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Nice work, $First_Name. Deploying to production server on branch $GITHUB_REF"
        env:
          First_Name: Mona

Скрипты в рабочем процессе

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

jobs:
  example-job:
    steps:
      - run: npm install -g bats

В этом примере вы используете npm для установки пакета тестирования программного bats обеспечения с помощью run ключевое слово. Также можно выполнить скрипт как действие. Скрипт можно сохранить в репозитории, часто в каталоге .github/scripts/, а затем указать путь и тип оболочки с помощью ключевого слова run.

jobs:
  example-job:
    steps:
      - name: Run build script
        run: ./.github/scripts/build.sh
        shell: bash

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

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

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

Параметр Описание: Обязательное поле
Ключ. Ссылается на идентификатор ключа, созданный при сохранении и поиске кэша. Да
Путь Указывает путь к файлу в средстве выполнения для кэширования или поиска. Да
Restore-keys состоит из альтернативных существующих ключей для кэшей, если требуемый ключ кэша не найден. No 
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 журналы выполнения рабочего процесса, можно сделать следующее:

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

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

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

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

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

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