Использование параллелизма в разных сценариях
Можно использовать jobs.<job_id>.concurrency, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Контексты разрешенных выражений: github,inputs , vars,needs ,strategy и .matrix Дополнительные сведения о выражениях см. в разделе Оценка выражений в рабочих процессах и действиях.
Можно также указать concurrency на уровне рабочего процесса. Дополнительные сведения см. в разделе concurrency.
Это означает, что в группе одновременно может быть максимум одна работающая задача или рабочий процесс. Если параллельное задание или рабочий процесс добавлены в очередь и выполняется другое задание или рабочий процесс, использующие ту же группу параллелизма в репозитории, то находящиеся в очереди задание или рабочий процесс будут pending. По умолчанию любая существующая pending задача или рабочий процесс в той же группе параллелизма будет отменена, и на её место займёт новая очередная задача или рабочий процесс.
Чтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите cancel-in-progress: true. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать cancel-in-progress как выражение с любым из контекстов разрешенного выражения.
Чтобы позволить pending нескольким задачам или рабочим процессам ожидать в одной группе параллелизма, используйте опциональное queue свойство. Свойство queue принимает следующие значения:
single(по умолчанию): В группе параллелизма можетpendingнаходиться максимум одна задача или запуск рабочего процесса. Когда новая задача или рабочий процесс ставится в очередь, любая существующаяpendingзадача или рабочий процесс, запущенный в той же группе, отменяется и заменяется.max: В группе параллелизма можетpendingбыть до 100 заданий или запусков рабочих процессов. Когда очередь заполнена, любые дополнительные задания или запуски рабочих процессов отменяются.
Комбинация queue: max и cancel-in-progress: true не допускается и приведёт к ошибке валидации рабочего процесса.
Примечание.
- Имя группы параллелизма не учитывает регистр. Например,
prodиProdбудет рассматриваться как та же группа параллелизма. - Задания или рабочие процессы в одной и той же группе параллелизма обрабатываются в порядке «первый вошёл — первый ушёл» (FIFO) в зависимости от времени ожидания группы параллелизма, а не по времени отправки каждого рабочего процесса. Поскольку фактическое время начала работы или запуска может различаться, заказ не гарантируется.
Пример. Использование параллелизма и поведения по умолчанию
По умолчанию 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
Пример: очередь на несколько ожидающих запусков
По умолчанию в группе параллелизма может pending находиться только одна задача или запуск рабочего процесса. Чтобы позволить несколько забегов выстраиваться в очередь вместо отмены, установите queue: max. При queue: max, до 100 заданий или запусков рабочих процессов могут подождать в группе параллелизма; после заполнения очереди любые дополнительные запуски отменяются.
Например, следующие рабочие процессы ставят в очередь развертывания в production среду, обрабатывая их по одному в порядке в зависимости от того, когда каждый запуск начинал ожидание группы параллелизма:
on:
push:
branches:
- main
concurrency:
group: production-deploy
queue: max
Обратите внимание, что queue: max нельзя комбинировать с cancel-in-progress: true, поскольку оба варианта описывают противоречивые действия при обработке запусков в процессе.
Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска
Чтобы использовать параллелизм для отмены любой текущей задачи или запускаGitHub Actions, вы можете использовать concurrency ключ с опциейtrue:cancel-in-progress
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, в вашей организации или предприятии. Дополнительные сведения см. в разделе Просмотр текущих заданий.