Кратко

  • Конкурентное выполнение в GitHub Actions относится к заданиям или запускам workflow, которые разрешаются в одну именованную группу; ожидающая работа может заменяться, вставать в очередь или отменяться в зависимости от настройки.
  • GitHub отдельно описывает concurrency и environment: другой workflow, использующий то же окружение, не становится автоматически объектом правила выбранной группы.
  • Утверждение о последовательном развертывании требует связать развернутый ключ группы, состав и состояние участников, записи исполнения и наблюдение за целью; одного названия группы в конфигурации недостаточно.

Фраза «production выполняется последовательно» нередко передает намерение проектирования, а не установленный факт. В GitHub Actions у workflow или задания можно объявить группу конкурентного выполнения. Правило способно запретить параллельное исполнение именованной работы, заменить ожидающий запуск более новым либо, когда очередь выбрана явно, сохранить дополнительную ожидающую работу. Это полезный контроль планирования. Однако группа не охватывает каждый путь, который может коснуться целевой системы. Ее граница начинается с заданий и запусков, действительно разрешающихся в эту группу.

Обычное поведение требует аккуратного прочтения. GitHub описывает для группы одну выполняющуюся и одну ожидающую единицу работы; новый ожидающий кандидат может заменить прежнего. queue: max меняет этот режим, разрешая ограниченную очередь, тогда как cancel-in-progress: true может остановить уже начавшуюся работу. Это разные исходы. Запись о постановке запуска в очередь не доказывает, что прежний ожидающий запуск остался доступен. Запись об отмене не показывает, какие шаги успели завершиться до нее. Ее нельзя читать как подтверждение отсутствия внешнего вызова, публикации артефакта или изменения цели.

Порядок также нельзя вывести из имени. GitHub описывает FIFO-обработку работы в очереди от времени, когда запуск начал ждать, и оговаривает, что фактическое время старта может отличаться. Поэтому группа не заменяет универсальную хронологию. Для утверждения о порядке нужны эффективный развернутый ключ, идентификаторы всех существенных заданий или запусков, время ожидания, старта и завершения, а также идентичность использованных исходников и артефакта. Одного отображаемого времени dispatch недостаточно.

В рассуждении о развертывании особенно важна граница между concurrency и environment. GitHub прямо говорит, что они не соединены: значением concurrency может быть любая строка, а workflow, использующий то же environment без указания группы, не подчиняется правилу этой группы. У environment могут быть собственные средства контроля — правила защиты и секреты. Они не заменяют общее выражение группы; общее выражение, в свою очередь, не является универсальной блокировкой environment. Это разные поверхности конфигурации.

API групп конкурентного выполнения может показать активных членов группы с идентификаторами run или job и состоянием pending либо in-progress. Это ценное операционное свидетельство, но его область ограничена текущим состоянием платформы. Оно не является журналом всех прошлых команд и не сообщает состояние целевой системы. Последующая проверка цели остается отдельной записью, в которой необходимы метод и время.

Daniel Kade предлагает семичастный «квитанционный пакет последовательности»: сохранить выражение concurrency и развернутый ключ; политику очереди и отмены; участие каждого значимого run и job с временем и состоянием; точный commit и неизменяемый артефакт; отдельно выбор environment; свидетельство исполнения; и ограниченное по времени наблюдение за целью. Чувствительные детали цели можно защитить. Недостающие связи следует оставить явными, а не достраивать их уверенностью, которую создает название группы.

Источники

  1. GitHub Docs — Concurrency
  2. GitHub Docs — Workflow syntax
  3. GitHub Docs — Deploying with GitHub Actions
  4. GitHub Docs — Actions concurrency groups REST API