fix(ci): jobs dependentes de changes falham de verdade quando changes falha [INFRA-67721] #26

Merged

tarcisio merged 1 commit from fix/INFRA-67721-gate-agregador into main

2026-10-01 07:56:47 -03:00

tmf-ia commented

2026-10-01 07:42:12 -03:00

Owner

O quê

Nos jobs gates, backend e frontend do ci.yml (CI único): if: ${{ always() }} + um primeiro step "Guarda — changes passou?" que dá exit 1 se needs.changes.result != success. O teste de contrato passa a aceitar só always() como if de job e exige a guarda como primeiro step.

Por quê

needs: changes sem always() fazia o Forgejo pular os dependentes quando changes falhava, e publicar job pulado como success (gate falso). Medido no tmf-platform em 29/09: changes "Failing after 1s" + 13 jobs "Has been skipped" com estado success.

Como testar

python3 -m unittest discover -s tests/ci-unico -v
Verificado: 26 testes OK. Controle negativo: o teste novo falha no ci.yml de origin/main ("gates: sem always() o job é pulado quando changes falha").

⚠ Não provado em runner

Depende de o act_runner aceitar always() sem o erro 'runs-on' key not defined (tmf9 #761, que motivou a regra "nenhum if: de job"). Com always() em job cujo needs falhou (não pulado) deve funcionar, mas só um run real confirma. Exige run real antes de ser adotado pelos produtos.
O mesmo defeito existe no ci-base.yml (dependentes de changes sem guarda) e não foi alterado aqui.

Refs: INFRA-67721

🤖 Generated with Claude Code

https://claude.ai/code/session_01G2e3V17tRc4mAZ4ea1XX1e

## O quê Nos jobs `gates`, `backend` e `frontend` do `ci.yml` (CI único): `if: ${{ always() }}` + um primeiro step **"Guarda — changes passou?"** que dá `exit 1` se `needs.changes.result != success`. O teste de contrato passa a aceitar só `always()` como `if` de job e exige a guarda como primeiro step. ## Por quê `needs: changes` sem `always()` fazia o Forgejo **pular** os dependentes quando `changes` falhava, e publicar job pulado como **success** (gate falso). Medido no tmf-platform em 29/09: `changes` "Failing after 1s" + 13 jobs "Has been skipped" com estado success. ## Como testar `python3 -m unittest discover -s tests/ci-unico -v` **Verificado:** 26 testes OK. **Controle negativo:** o teste novo **falha** no `ci.yml` de `origin/main` ("gates: sem always() o job é pulado quando changes falha"). ## ⚠ Não provado em runner Depende de o `act_runner` aceitar `always()` sem o erro `'runs-on' key not defined` (tmf9 #761, que motivou a regra "nenhum `if:` de job"). Com `always()` em job cujo `needs` **falhou** (não pulado) deve funcionar, mas só um run real confirma. **Exige run real antes de ser adotado pelos produtos.** O mesmo defeito existe no `ci-base.yml` (dependentes de `changes` sem guarda) e **não** foi alterado aqui. Refs: INFRA-67721 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01G2e3V17tRc4mAZ4ea1XX1e

tmf-ia added 1 commit

2026-10-01 07:42:12 -03:00

fix(ci): jobs dependentes de changes falham de verdade quando changes falha [INFRA-67721] e04ec29b55

needs: changes sem always() pulava gates/backend/frontend, e o Forgejo publica
job pulado como success (gate falso, tmf-platform 29/09: changes 'Failing after
1s' + 13 jobs 'Has been skipped' success).

- gates/backend/frontend: if: always() (nunca falso, nunca vira skipped) + 1o
  step 'Guarda' que da exit 1 se needs.changes.result != success.
- teste: so always() permitido como if de job; guarda obrigatoria como 1o step.
  Controle negativo: o teste novo falha no ci.yml de origin/main.

NAO provado em runner: depende de o act_runner aceitar always() sem o erro
'runs-on key not defined' (tmf9 #761). Exige run real antes de merge.

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