Resumo

  • A concorrência do GitHub Actions alcança jobs ou execuções de workflow que compartilham um grupo resolvido pelo mesmo nome; trabalho pendente pode ser substituído, enfileirado ou cancelado conforme a configuração.
  • A documentação do GitHub separa concorrência de environment: outro workflow que use o mesmo ambiente não fica sujeito automaticamente a um grupo escolhido.
  • Para afirmar que uma implantação foi serializada, é preciso reunir a chave de grupo expandida, membros e disposições, registros de execução e observação do alvo — não apenas o nome configurado do grupo.

“A produção está serializada” costuma ser uma intenção de desenho apresentada como se fosse observação. GitHub Actions permite declarar um grupo de concorrência no workflow ou no job. A regra pode impedir que trabalho nomeado execute em paralelo, substituir uma execução pendente por uma mais nova ou, quando a fila é escolhida explicitamente, reter mais trabalho à espera. É um controle útil de agendamento. Mas o grupo não acompanha todas as rotas que podem tocar um destino. Seu alcance começa nos jobs e nas execuções que de fato se resolvem naquele grupo.

O comportamento padrão exige leitura cuidadosa. A documentação descreve, para um grupo, uma unidade em andamento e uma pendente; uma nova candidata pendente pode substituir a anterior. queue: max altera o caso ao permitir uma fila limitada, enquanto cancel-in-progress: true pode interromper trabalho que já está em execução. Essas disposições não são equivalentes. O registro de que uma execução entrou na fila não demonstra que a execução pendente anterior continuou disponível. O registro de cancelamento tampouco informa quais etapas já terminaram antes dele. Não serve como prova de que não houve chamada externa, publicação de artefato ou alteração no alvo.

Há também uma questão de ordenação. O GitHub descreve tratamento FIFO para trabalho enfileirado a partir do momento em que a execução começou a aguardar, e ressalva que a hora real de início pode variar. Logo, um grupo não deve ser usado como abreviação para uma narrativa cronológica universal. Uma afirmação de ordem requer a chave efetiva já expandida, as identidades de todos os jobs ou runs pertinentes, seus tempos de espera, início e conclusão, e as identidades do código-fonte e do artefato utilizados. A hora visível de dispatch, sozinha, não resolve a questão.

Na linguagem de implantação, a distinção entre concorrência e environment é decisiva. O GitHub declara que os dois não são conectados: o valor de concorrência pode ser qualquer string, e um workflow que usa o mesmo environment sem especificar o grupo não se sujeita à regra desse grupo. Um environment pode impor controles próprios, como regras de proteção e segredos. Eles não substituem uma expressão de grupo compartilhada; uma expressão compartilhada, por sua vez, não é um cadeado universal sobre o environment. São superfícies de configuração separadas.

A API de grupos de concorrência pode mostrar membros ativos de um grupo, com identificadores de run ou job e estado pending ou in-progress. Isso é evidência operacional útil, mas limitada ao presente e à plataforma. Não é um inventário de todo comando passado nem uma leitura do estado do alvo. Uma conferência posterior do alvo continua sendo um registro distinto, que precisa declarar método e horário.

Daniel Kade propõe um recibo de serialização com sete partes: guardar a expressão de concorrência e a chave expandida; a política de fila e cancelamento; a participação de cada run e job relevante com tempos e disposição; o commit exato e o artefato imutável; a seleção de environment separadamente; a evidência de execução; e uma observação delimitada do alvo. Detalhes sensíveis podem permanecer protegidos. O que falta entre esses registros deve ficar explícito, em vez de ser preenchido pela tranquilidade que um nome de grupo transmite.

Fontes

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