{"meta":{"title":"Управление параллелизмом рабочих процессов и заданий","intro":"Управление рабочими процессами и заданиями, которые могут выполняться одновременно.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/how-tos","title":"Инструкции"},{"href":"/ru/actions/how-tos/write-workflows","title":"Написание рабочих процессов"},{"href":"/ru/actions/how-tos/write-workflows/choose-when-workflows-run","title":"Выбор времени выполнения рабочих процессов"},{"href":"/ru/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency","title":"Управление параллелизмом рабочего процесса"}],"documentType":"article"},"body":"# Управление параллелизмом рабочих процессов и заданий\n\nУправление рабочими процессами и заданиями, которые могут выполняться одновременно.\n\n## Использование параллелизма в разных сценариях\n\nМожно использовать `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).\n\nМожно также указать `concurrency` на уровне рабочего процесса. Дополнительные сведения см. в разделе [`concurrency`](/ru/actions/reference/workflows-and-actions/workflow-syntax#concurrency).\n\nЭто означает, что в группе одновременно может быть максимум одна работающая задача или рабочий процесс. Если параллельное задание или рабочий процесс добавлены в очередь и выполняется другое задание или рабочий процесс, использующие ту же группу параллелизма в репозитории, то находящиеся в очереди задание или рабочий процесс будут `pending`. По умолчанию любая существующая `pending` задача или рабочий процесс в той же группе параллелизма будет отменена, и на её место займёт новая очередная задача или рабочий процесс.\n\nЧтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите `cancel-in-progress: true`. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать `cancel-in-progress` как выражение с любым из контекстов разрешенного выражения.\n\nЧтобы позволить `pending` нескольким задачам или рабочим процессам ожидать в одной группе параллелизма, используйте опциональное `queue` свойство. Свойство `queue` принимает следующие значения:\n\n* `single` (по умолчанию): В группе параллелизма может `pending` находиться максимум одна задача или запуск рабочего процесса. Когда новая задача или рабочий процесс ставится в очередь, любая существующая `pending` задача или рабочий процесс, запущенный в той же группе, отменяется и заменяется.\n* `max`: В группе параллелизма может `pending` быть до 100 заданий или запусков рабочих процессов. Когда очередь заполнена, любые дополнительные задания или запуски рабочих процессов отменяются.\n\nКомбинация `queue: max` и `cancel-in-progress: true` не допускается и приведёт к ошибке валидации рабочего процесса.\n\n> \\[!NOTE]\n>\n> * Имя группы параллелизма не учитывает регистр. Например, `prod` и `Prod` будет рассматриваться как та же группа параллелизма.\n> * Задания или рабочие процессы в одной и той же группе параллелизма обрабатываются в порядке «первый вошёл — первый ушёл» (FIFO) в зависимости от времени ожидания группы параллелизма, а не по времени отправки каждого рабочего процесса. Поскольку фактическое время начала работы или запуска может различаться, заказ не гарантируется.\n\n### Пример. Использование параллелизма и поведения по умолчанию\n\nПо умолчанию GitHub Actions режим позволяет выполнять несколько заданий или рабочих процессов одновременно. Ключевое `concurrency` слово позволяет управлять параллелизмом выполнения рабочих процессов.\n\nНапример, ключевое `concurrency` слово можно использовать сразу после определения условий триггера, чтобы ограничить параллелизм всего рабочего процесса для определенной ветви:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\nКроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью `concurrency` ключевого слова на уровне задания:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: example-group\n      cancel-in-progress: true\n```\n\n### Пример: группы параллелизма\n\nГруппы параллелизма предоставляют способ управления выполнением и ограничением выполнения выполнения рабочих процессов или заданий, использующих один и тот же ключ параллелизма.\n\nКлюч `concurrency` используется для группировки рабочих процессов или заданий в группу параллелизма. Когда вы определяете ключ `concurrency` , GitHub Actions убедитесь, что в любой момент времени работает только один рабочий процесс или задание с этим ключом. Если новый рабочий процесс или задание начинается с того же `concurrency` ключа, GitHub Actions все рабочие процессы или задания с этим ключом отменяются. Ключ `concurrency` может быть жестко закодированной строкой или может быть динамическим выражением, которое включает в себя переменные контекста.\n\nМожно определить условия параллелизма в рабочем процессе, чтобы рабочий процесс или задание были частью группы параллелизма.\n\nЭто означает, что при запуске или запуске рабочего процесса GitHub отменяет все запуски рабочих процессов или задания, которые уже выполняются в той же группе параллелизма. Это полезно в сценариях, в которых требуется предотвратить параллельные запуски для определенного набора рабочих процессов или заданий, таких как те, которые используются для развертываний в промежуточной среде, чтобы предотвратить действия, которые могут вызвать конфликты или использовать больше ресурсов, чем необходимо.\n\nВ этом примере `job-1` является частью группы параллелизма с именем `staging_environment`. Это означает, что если запускается новый запуск `job-1` , все запуски того же задания в `staging_environment` группе параллелизма, которые уже выполняются, будут отменены.\n\n```yaml\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: staging_environment\n      cancel-in-progress: true\n```\n\nКроме того, использование динамического выражения, например `concurrency: ci-${{ github.ref }}` в рабочем процессе, означает, что рабочий процесс или задание будет частью группы `ci-` параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ci-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### Пример: очередь на несколько ожидающих запусков\n\nПо умолчанию в группе параллелизма может `pending` находиться только одна задача или запуск рабочего процесса. Чтобы позволить несколько забегов выстраиваться в очередь вместо отмены, установите `queue: max`. При `queue: max`, до 100 заданий или запусков рабочих процессов могут подождать в группе параллелизма; после заполнения очереди любые дополнительные запуски отменяются.\n\nНапример, следующие рабочие процессы ставят в очередь развертывания в `production` среду, обрабатывая их по одному в порядке в зависимости от того, когда каждый запуск начинал ожидание группы параллелизма:\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: production-deploy\n  queue: max\n```\n\nОбратите внимание, что `queue: max` нельзя комбинировать с `cancel-in-progress: true`, поскольку оба варианта описывают противоречивые действия при обработке запусков в процессе.\n\n### Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска\n\nЧтобы использовать параллелизм для отмены любой текущей задачи или запускаGitHub Actions, вы можете использовать `concurrency` ключ с опцией`true`:`cancel-in-progress`\n\n```yaml\nconcurrency:\n  group: ${{ github.ref }}\n  cancel-in-progress: true\n```\n\nОбратите внимание, что в этом примере, без определения конкретной группы параллелизма, GitHub Actions\\_будет отменён любой\\_ текущий запуск задания или рабочего процесса.\n\n### Пример. Использование резервного значения\n\nЕсли вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, `github.head_ref` определяется только для событий `pull_request`. Если рабочий процесс реагирует на другие события в дополнение к событиям `pull_request`, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях `pull_request`. Если параметр `github.head_ref` не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным.\n\n```yaml\nconcurrency:\n  group: ${{ github.head_ref || github.run_id }}\n  cancel-in-progress: true\n```\n\n### Пример. Отмена только выполняемых заданий или запусков для текущего рабочего процесса\n\nПри наличии нескольких рабочих процессов в одном репозитории имена групп параллелизма должны быть уникальными в разных рабочих процессах, чтобы избежать отмены выполняемых заданий или запусков из других рабочих процессов. В противном случае все ранее выполняемые или ожидающие задания будут отменены независимо от рабочего процесса.\n\nЧтобы отменить только выполняемые запуски для одного рабочего процесса, можно использовать свойство `github.workflow` для создания группы параллелизма:\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### Пример. Отмена только выполняемых заданий в определенных ветвях\n\nЕсли вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с `cancel-in-progress`. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска.\n\nЧтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать `cancel-in-progress` выражение, аналогичное следующему:\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nВ этом примере несколько push-уведомлений в `release/1.2.3` ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например `main`, отменяет выполняемые запуски.\n\n## Мониторинг текущих заданий в организации или предприятии\n\nЧтобы определить ограничения с параллелизмом или очередью, можно проверить, сколько заданий в настоящее время обрабатывается на GitHubразмещенных в вашей организации или предприятиях. Дополнительные сведения см. в разделе [Просмотр текущих заданий](/ru/actions/how-tos/manage-runners/github-hosted-runners/view-current-jobs)."}