Сведения о рабочих процессах

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

Рабочие процессы определяются в каталоге .github/workflows в репозитории, а репозиторий может иметь несколько рабочих процессов, каждый из которых может выполнять разные наборы задач. Например, у вас может быть один рабочий процесс для создания и тестирования запросов на вытягивание, другой рабочий процесс — для развертывания приложения при каждом создании выпуска, а также еще один рабочий процесс, добавляющий метку каждый раз, когда кто-то открывает новую проблему.

Основы рабочих процессов

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

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

Дополнительные сведения об этих основных компонентах см. в разделе "Общие сведения о GitHub Actions".

Схема триггера события Runner 1 для запуска задания 1, которая активирует Runner 2 для запуска задания 2. Каждая из заданий разбивается на несколько шагов.

Активация рабочего процесса

Триггеры рабочего процесса — это события, которые приводят к запуску рабочего процесса. Эти события могут быть следующими:

События, происходящие в репозитории рабочего процесса
События, происходящие за пределами GitHub Enterprise Server и запускающие событие repository_dispatch в GitHub Enterprise Server
Запланированное время
Руководство

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

Дополнительные сведения см. в разделе "[AUTOTITLE" и полный список событий см. в разделеСобытия, инициирующие рабочие процессы](/actions/using-workflows/triggering-a-workflow)".

Синтаксис рабочего процесса

Рабочий процесс определяется с помощью формата YAML. Полный справочник по синтаксису YAML для рабочих процессов разработки см. в разделе "Синтаксис рабочего процесса для GitHub Actions".

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

Для определения рабочего процесса GitHub Actions использует синтаксис YAML. Каждый рабочий процесс хранится как отдельный YAML-файл в репозитории кода в каталоге с именем .github/workflows.

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

В репозитории создайте каталог .github/workflows/ для хранения файлов рабочего процесса.

В каталоге .github/workflows/ создайте файл с именем learn-github-actions.yml и добавьте следующий код.

YAML

name: learn-github-actions
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats
      - run: bats -v

name: learn-github-actions
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats
      - run: bats -v

Зафиксируйте эти изменения и отправьте их в репозиторий GitHub.

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

Общие сведения о файле рабочего процесса

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

YAML

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions

# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
- uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 20.) This puts both the `node` and `npm` commands in your `PATH`.
- uses: actions/setup-node@v4
with:
node-version: '20'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
- run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
- run: bats -v

name: learn-github-actions

Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.

run-name: ${{ github.actor }} is learning GitHub Actions

Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the github context to display the username of the actor that triggered the workflow run. For more information, see "Синтаксис рабочего процесса для GitHub Actions."

on: [push]

Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Синтаксис рабочего процесса для GitHub Actions."

jobs:

Groups together all the jobs that run in the learn-github-actions workflow.

  check-bats-version:

Defines a job named check-bats-version. The child keys will define properties of the job.

    runs-on: ubuntu-latest

Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "Синтаксис рабочего процесса для GitHub Actions"

    steps:

Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell script.

      - uses: actions/checkout@v4

The uses keyword specifies that this step will run v4 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

This step uses the actions/setup-node@v4 action to install the specified version of the Node.js. (This example uses version 20.) This puts both the node and npm commands in your PATH.

      - run: npm install -g bats

The run keyword tells the job to execute a command on the runner. In this case, you are using npm to install the bats software testing package.

      - run: bats -v

Finally, you'll run the bats command with a parameter that outputs the software version.

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions

# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 20.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - run: bats -v

Визуализация файла рабочего процесса

На этой схеме показан только что созданный файл рабочего процесса и порядок организации компонентов GitHub Actions в иерархии. Каждый этап выполняет одно действие или скрипт оболочки. Этапы 1 и 2 выполняют действия, а этапы 3 и 4 выполняют скрипты оболочки. Дополнительные предварительно созданные действия для рабочих процессов см. в разделе "Поиск и настройка действий".

Схема, показывающая триггер, средство выполнения и задание рабочего процесса. Задание разбито на 4 шага.

Просмотр действия для выполнения рабочего процесса

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

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

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

Использование начальных рабочих процессов

GitHub предоставляет предварительно настроенные начальные рабочие процессы, которые можно настроить для создания собственного рабочего процесса непрерывной интеграции. GitHub Enterprise Server анализирует код и показывает начальные рабочие процессы CI, которые могут быть полезны для репозитория. Например, если репозиторий содержит код Node.js, вы увидите предложения для проектов Node.js. Начальные рабочие процессы могут быть отправной точкой для создания пользовательского рабочего процесса, или же его можно использовать в том виде, как есть.

Полный список начальных рабочих процессов можно просмотреть в репозитории actions/starter-workflows в репозитории ваш экземпляр GitHub Enterprise Server.

Дополнительные сведения об использовании и создании начальных рабочих процессов см. в разделе "[AUTOTITLE" и "Использование начальных рабочих процессов](/actions/using-workflows/creating-starter-workflows-for-your-organization)".

Расширенные функции рабочих процессов

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

Хранение секретов

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

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

jobs:
  example-job:
    runs-on: ubuntu-latest
    steps:
      - name: Retrieve secret
        env:
          super_secret: ${{ secrets.SUPERSECRET }}
        run: |
          example-command "$super_secret"

Дополнительные сведения см. в разделе Использование секретов в GitHub Actions.

Создание зависимых заданий

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

В этом примере задания setup, build и test выполняются вместе, а задания build и test также зависят от успешного завершения задания, предшествующего им.

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - run: ./setup_server.sh
  build:
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - run: ./build_server.sh
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./test_server.sh

Дополнительные сведения см. в разделе Использование заданий в рабочем процессе.

Использование матрицы

Стратегия матрицы позволяет использовать переменные в одном определении задания для автоматического создания нескольких выполнений заданий, основанных на сочетаниях переменных. Например, можно использовать стратегию матрицы для тестирования кода в нескольких версиях языка или в нескольких операционных системах. Матрица создается с помощью ключевого слова strategy, которое получает параметры сборки в виде массива. Например, следующая матрица будет выполнять задание несколько раз, используя разные версии Node.js.

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [14, 16]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}

Дополнительные сведения см. в разделе Использование матрицы для заданий.

Кэширование зависимостей

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

В этом примере показано, как кэшировать каталог ~/.npm:

jobs:
  example-job:
    steps:
      - name: Cache node modules
        uses: actions/cache@v3
        env:
          cache-name: cache-node-modules
        with:
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-

Дополнительные сведения см. в разделе Кэширование зависимостей для ускорения рабочих процессов.

Использование баз данных и контейнеров служб

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

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie
    services:
      postgres:
        image: postgres
    steps:
      - name: Check out repository code
        uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Connect to PostgreSQL
        run: node client.js
        env:
          POSTGRES_HOST: postgres
          POSTGRES_PORT: 5432

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

Использование меток для маршрутизации рабочих процессов

Если вам нужно, что задание обрабатывал определенный тип средства выполнения, можно использовать метки для управления местом выполнения заданий. Метки можно назначить локальному средству выполнения в дополнение к метке по умолчанию self-hosted. Затем вы можете ссылаться на эти метки в рабочем процессе YAML, гарантируя, что задание направляется предсказуемым образом. GitHubразмещенные в среде runners назначены предопределенные метки.

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

jobs:
  example-job:
    runs-on: [self-hosted, linux, x64, gpu]

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

Дополнительные сведения о метках локального runner см. в разделе "Использование меток с самостоятельно размещенными средствами выполнения".

Повторное использование рабочих процессов

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

Защита безопасности для рабочих процессов

GitHub предоставляет функции безопасности, которые можно использовать для повышения безопасности рабочих процессов. Встроенные функции %% данных variables.product.prodname_dotcom %}позволяют получать уведомления об уязвимостях в используемых действиях или автоматизировать процесс поддержания действий в рабочих процессах. Дополнительные сведения см. в разделе Использование функций безопасности GitHub для защиты использования GitHub Actions.

Использование сред

Среды можно настроить с помощью правил защиты и секретов для управления выполнением заданий в рабочем процессе. Каждое задание в рабочем процессе может ссылаться на одну среду. Чтобы задание, ссылающееся на среду, было отправлено в средство выполнения, должны быть выполнены все правила защиты среды. Дополнительные сведения см. в разделе Использование сред для развертывания.

Сведения о рабочих процессах

В этой статье