feat(ci): chamador único cancela o run superado no push de develop, nunca o da release [INFRA-68076] #51

Merged

tarcisio merged 1 commit from feat/INFRA-68076-cancelar-superados-develop into develop

2026-10-05 20:06:09 -03:00

tmf-ia commented

2026-10-05 18:42:11 -03:00

Owner

O que muda

INFRA-68076 (parte do CI). O bloco concurrency do chamador único (templates/ci-chamador.yml) passa a cancelar o run superado também no push em develop:

pull_request → ci-pr-<n>, cancela (como antes);
push em develop → ci-develop (um grupo), cancela o run do commit anterior (novo);
push em main (release/deploy) → por ref+sha, nunca cancela (prioridade da release; padrão HelpCor, HCOR-64869);
outra ref → por ref+sha, sem cancelar. O push em epic/** não dispara o CI (só o PR).

A regra mora no chamador porque é ele que define o grupo; o reusável não tem concurrency.

Transição (sem quebrar a frota)

O chamador é copiado idêntico em cada produto (gate conferir-ci-identico.sh). templates/ci-chamador.anterior.yml guarda o template de antes byte a byte: o produto que ainda tem a cópia antiga passa com aviso, não vermelho, até copiar o novo. Apague o .anterior quando a frota migrar.

Testes

tests/ci-unico/test_fila_concorrencia.py avalia a expressão (tradutor mínimo de &&, ||, format, github.*) por evento e prova: PR cancela; dois pushes em develop caem no mesmo grupo e cancelam; pushes em main caem em grupos diferentes e nunca cancelam; outra ref não cancela. Controle: o template anterior não cancelava o push em develop (e o teste reprova se o template novo for trocado pelo antigo). Todas as pastas de teste passam (hub-issue-sync e release não rodei por serem lentas/skip).

⚠️ Limites

Não muda nenhum produto até (1) a develop do ci-shared ir à main (/deploy-safe) e (2) cada produto copiar o template novo. Aceite da issue ("os 3 produtos em foco com cancel-in-progress em develop") fica aberto até a adoção (Platform TMFP-68059, DANI e o Hub já tem o seu).
O TMF9 e o TMF7 não usam este chamador.
Efeito a aceitar: o run do commit anterior da develop passa a ficar cancelled quando outro push chega; só o topo da develop tem CI completo.
Fora do reusável (ficam como política/porteira, texto no ORG pelo Lineu): "máx. 5 PRs abertos por produto" (não medi como gate; seria um check no pr.py abrir), "develop vermelha segura os PRs" (a porteira conferir-antes-de-abrir-pr.sh já recusa PR com base vermelha) e "release tem prioridade sobre pushes não urgentes de outros produtos".
Não verifiquei se o Forgejo 15 avalia &&/|| nesta forma no group: além do que o template antigo já usava (o antigo já combinava && e || e format); o primeiro push em develop depois da adoção confirma.

🤖 Generated with Claude Code

https://claude.ai/code/session_019nhmgPciDjRhb5KSiZrePM

## O que muda INFRA-68076 (parte do CI). O bloco `concurrency` do **chamador único** (`templates/ci-chamador.yml`) passa a cancelar o run superado também no **push em `develop`**: - `pull_request` → `ci-pr-<n>`, cancela (como antes); - **`push` em `develop` → `ci-develop` (um grupo), cancela o run do commit anterior** (novo); - `push` em `main` (release/deploy) → por ref+sha, **nunca cancela** (prioridade da release; padrão HelpCor, HCOR-64869); - outra ref → por ref+sha, sem cancelar. O push em `epic/**` não dispara o CI (só o PR). A regra mora no chamador porque é ele que define o grupo; o reusável não tem `concurrency`. ## Transição (sem quebrar a frota) O chamador é copiado idêntico em cada produto (gate `conferir-ci-identico.sh`). `templates/ci-chamador.anterior.yml` guarda o template de antes **byte a byte**: o produto que ainda tem a cópia antiga passa com **aviso**, não vermelho, até copiar o novo. Apague o `.anterior` quando a frota migrar. ## Testes `tests/ci-unico/test_fila_concorrencia.py` avalia a expressão (tradutor mínimo de `&&`, `||`, `format`, `github.*`) **por evento** e prova: PR cancela; dois pushes em develop caem no mesmo grupo e cancelam; pushes em main caem em grupos diferentes e **nunca** cancelam; outra ref não cancela. **Controle:** o template anterior não cancelava o push em develop (e o teste reprova se o template novo for trocado pelo antigo). Todas as pastas de teste passam (hub-issue-sync e release não rodei por serem lentas/skip). ## ⚠️ Limites - **Não muda nenhum produto até** (1) a `develop` do ci-shared ir à `main` (`/deploy-safe`) e (2) cada produto copiar o template novo. Aceite da issue ("os 3 produtos em foco com cancel-in-progress em develop") fica **aberto** até a adoção (Platform TMFP-68059, DANI e o Hub já tem o seu). - O TMF9 e o TMF7 não usam este chamador. - **Efeito a aceitar:** o run do commit anterior da develop passa a ficar `cancelled` quando outro push chega; só o topo da develop tem CI completo. - **Fora do reusável** (ficam como política/porteira, texto no ORG pelo Lineu): "máx. 5 PRs abertos por produto" (não medi como gate; seria um check no `pr.py abrir`), "develop vermelha segura os PRs" (a porteira `conferir-antes-de-abrir-pr.sh` já recusa PR com base vermelha) e "release tem prioridade sobre pushes não urgentes de outros produtos". - Não verifiquei se o Forgejo 15 avalia `&&`/`||` nesta forma no `group:` além do que o template antigo já usava (o antigo já combinava `&&` e `||` e `format`); o primeiro push em develop depois da adoção confirma. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_019nhmgPciDjRhb5KSiZrePM

tmf-ia added 1 commit

2026-10-05 18:42:12 -03:00

feat(ci): chamador unico cancela o run superado no push de develop, nunca o da release [INFRA-68076]

PR checks (ci-shared) / testes (pull_request) Successful in 2m37s

Details

06a1226332

Decisao do operador (01/10/2026): run superado nao pode ocupar o runner. O bloco concurrency do templates/ci-chamador.yml passa a
usar o grupo ci-develop e cancel-in-progress tambem no push de develop (antes so em PR); o push de main (release/deploy) segue por
ref+sha e nunca cancela. templates/ci-chamador.anterior.yml guarda o template de antes byte a byte: o produto que ainda tem a
copia antiga passa no conferir-ci-identico com aviso ate migrar. Teste avalia a expressao por evento (PR, develop, main, outra ref)
e usa o template anterior como controle. README documenta a regra e o que fica fora do reusavel (max 5 PRs, develop vermelha,
prioridade de release entre produtos).

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019nhmgPciDjRhb5KSiZrePM