# Управление параллелизмом рабочих процессов и заданий

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

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

Можно использовать `jobs.<job_id>.concurrency`, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Контексты разрешенных выражений: `github`[](/ru/actions/reference/workflows-and-actions/contexts#github-context),`inputs`[](/ru/actions/reference/workflows-and-actions/contexts#inputs-context) , `vars`[](/ru/actions/reference/workflows-and-actions/contexts#vars-context),`needs`[](/ru/actions/reference/workflows-and-actions/contexts#needs-context) ,`strategy`[](/ru/actions/reference/workflows-and-actions/contexts#strategy-context) и .[`matrix`](/ru/actions/reference/workflows-and-actions/contexts#matrix-context) Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).

Можно также указать `concurrency` на уровне рабочего процесса. Дополнительные сведения см. в разделе [`concurrency`](/ru/actions/reference/workflows-and-actions/workflow-syntax#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` не допускается и приведёт к ошибке валидации рабочего процесса.

> \[!NOTE]
>
> * Имя группы параллелизма не учитывает регистр. Например, `prod` и `Prod` будет рассматриваться как та же группа параллелизма.
> * Задания или рабочие процессы в одной и той же группе параллелизма обрабатываются в порядке «первый вошёл — первый ушёл» (FIFO) в зависимости от времени ожидания группы параллелизма, а не по времени отправки каждого рабочего процесса. Поскольку фактическое время начала работы или запуска может различаться, заказ не гарантируется.

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

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

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

```yaml
on:
  push:
    branches:
      - main

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

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

```yaml
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` группе параллелизма, которые уже выполняются, будут отменены.

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

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

```yaml
on:
  push:
    branches:
      - main

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

### Пример: очередь на несколько ожидающих запусков

По умолчанию в группе параллелизма может `pending` находиться только одна задача или запуск рабочего процесса. Чтобы позволить несколько забегов выстраиваться в очередь вместо отмены, установите `queue: max`. При `queue: max`, до 100 заданий или запусков рабочих процессов могут подождать в группе параллелизма; после заполнения очереди любые дополнительные запуски отменяются.

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

```yaml
on:
  push:
    branches:
      - main

concurrency:
  group: production-deploy
  queue: max
```

Обратите внимание, что `queue: max` нельзя комбинировать с `cancel-in-progress: true`, поскольку оба варианта описывают противоречивые действия при обработке запусков в процессе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы определить ограничения с параллелизмом или очередью, можно проверить, сколько заданий в настоящее время обрабатывается на GitHubразмещенных в вашей организации или предприятиях. Дополнительные сведения см. в разделе [Просмотр текущих заданий](/ru/actions/how-tos/manage-runners/github-hosted-runners/view-current-jobs).