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

Обзор

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

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

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

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

Можно использовать jobs.<job_id>.concurrency, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Контексты разрешенных выражений: github,inputs , vars,needs ,strategy и .matrix Дополнительные сведения о выражениях см. в разделе "Выражения".

Можно также указать concurrency на уровне рабочего процесса. Дополнительные сведения см. в разделе concurrency.

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

Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите cancel-in-progress: true. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать cancel-in-progress как выражение с любым из контекстов разрешенного выражения.

Пример. Использование параллелизма и поведения по умолчанию

Поведение по умолчанию GitHub Actions позволяет одновременно выполнять несколько заданий или рабочих процессов. Ключевое слово concurrency позволяет управлять параллелизмом выполнения рабочих процессов.

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

on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

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

on:
  push:
    branches:
      - main

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: example-group
      cancel-in-progress: true

Пример: группы параллелизма

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

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

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

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

В этом примере job-1 является частью группы параллелизма с именем staging_environment. Это означает, что если запускается новый запуск job-1 , все запуски того же задания в staging_environment группе параллелизма, которые уже выполняются, будут отменены.

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: staging_environment
      cancel-in-progress: true

Кроме того, использование динамического выражения, например concurrency: ci-${{ github.ref }} в рабочем процессе, означает, что рабочий процесс или задание будет частью группы ci- параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен:

on:
  push:
    branches:
      - main

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска

Чтобы использовать параллелизм для отмены любого выполняемого задания или запуска в GitHub Actions, можно использовать concurrency ключ с параметром cancel-in-progress :true

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

Обратите внимание, что в этом примере без определения определенной группы параллелизма GitHub Actions отменит выполнение задания или рабочего процесса.

Пример. Использование резервного значения

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

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

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

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

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

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Пример. Отмена только выполняемых заданий в определенных ветвях

Если вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с cancel-in-progress. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска.

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

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}

В этом примере несколько push-уведомлений в release/1.2.3 ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например main, отменяет выполняемые запуски.

Мониторинг текущих заданий в организации или предприятии

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