Você faz dois pushes seguidos para corrigir um deploy. O segundo entra na fila e o primeiro some. Às vezes isso é exatamente o comportamento desejado; em outras, é como descobrir tarde que uma migração, uma publicação ou uma validação ficou pelo caminho.
No GitHub Actions, a chave concurrency não é só um freio de mão para pipelines. Ela define quem pode rodar junto, quem espera e, dependendo da configuração, quem deixa de esperar. É uma decisão de operação — e não apenas uma linha de YAML copiada de outro repositório.
O detalhe que pega: pendência não é fila infinita
Quando duas execuções usam o mesmo grupo de concorrência, o GitHub limita o grupo a uma execução em andamento e, por padrão, uma pendente. Se chega outra execução para aquele mesmo grupo, a pendente anterior pode ser cancelada e substituída pela nova. Isso é ótimo para uma checagem de pull request que já ficou velha. Para um deploy que precisa acontecer na ordem certa, pode ser uma surpresa ruim.
Antes de configurar qualquer coisa, vale separar duas perguntas: esta execução ainda faz sentido se houver um commit mais novo? E se duas execuções alterarem o mesmo ambiente, uma pode passar por cima da outra? A primeira aponta para cancelamento; a segunda, para fila.
Três escolhas que resolvem problemas diferentes
1. PRs: cancele o que ficou velho
Para testes em uma branch de pull request, normalmente interessa o commit mais recente. Um grupo por branch com cancel-in-progress: true reduz consumo de runner e devolve feedback mais atual.
concurrency:
group: pr-${{ github.head_ref }}
cancel-in-progress: trueNão use esse padrão cegamente em fluxos com passos externos difíceis de reverter. Cancelar uma suíte de testes é uma coisa; interromper uma mudança de infraestrutura no meio é outra.
2. Deploys: enfileire quando a ordem importa
Se várias execuções publicam no mesmo ambiente, trate o ambiente como recurso compartilhado. A documentação atual do GitHub permite queue: max para manter até 100 execuções pendentes no grupo. Isso é útil quando cada deploy precisa passar, em vez de ser trocado pelo próximo push.
concurrency:
group: production-deploy
queue: maxHá uma restrição importante: queue: max e cancel-in-progress: true não combinam. Uma opção diz para preservar a espera; a outra manda derrubar trabalho em andamento.
3. Fluxos diferentes: não compartilhe o mesmo nome por acidente
O grupo vale no repositório, não só dentro de um arquivo de workflow. Um nome genérico como production pode fazer uma rotina de deploy interferir em outro workflow que usa o mesmo grupo. Quando o objetivo é isolar o próprio workflow, inclua github.workflow e a referência no nome.
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueO teste prático antes de subir a alteração
Crie duas execuções deliberadamente próximas e acompanhe a aba Actions. Faça uma para um pull request e outra para o ambiente que recebe deploy. A pergunta não é só se o YAML valida: é se, diante de dois pushes, o resultado corresponde ao risco real do seu fluxo.
- Para PR: o commit antigo deve ser interrompido sem deixar efeitos externos.
- Para produção: confirme se a sequência deve ser preservada ou se o último estado basta.
- Para release: verifique se o grupo não colide com workflow de rollback, migração ou aprovação manual.
Concorrência bem configurada economiza runner, reduz disputa de ambiente e deixa o comportamento previsível. A parte perigosa não é limitar execuções. É deixar o GitHub decidir uma política de fila que você nunca parou para escolher.
