feat(ci): tests_timeout_minutes por produto no ci.yml reusável, com motivo obrigatório [INFRA-68520] #50

Merged

tarcisio merged 1 commit from feat/INFRA-68520-tests-timeout-minutes into develop

2026-10-05 15:44:35 -03:00

tmf-ia commented

2026-10-05 15:35:38 -03:00

Owner

O que muda

tests_timeout_minutes no ci.yml reusável (INFRA-68520, pedido do Lineu para o CI do DANI). Antes o passo "Testes (completo)" tinha timeout-minutes: 30 fixo para toda a frota e o job backend 40 fixo.

Chave no ci-config (não é input do reusável): tests_timeout_minutes, padrão 30, de 5 a 90. Schema, ci_config.py, exemplo e README.
O teto do job sobe junto: derivado em ci_config.py como tests_timeout_minutes + 10 (backend_job_timeout_minutes, padrão 40). Nunca fica menor que passo + folga (teste cobre 5, 30, 60, 90).
Motivo obrigatório: valor diferente de 30 (maior ou menor) exige tests_timeout_motivo com ≥ 10 caracteres, senão o ci-config reprova. Exceção sem motivo é dívida.
ci.yml: passo e job leem os outputs do changes, com fallback literal igual ao padrão (|| 30, || 40).

Medido no runner real (sondas em branch, já removidas)

timeout-minutes com expressão é avaliado no passo e no job, nas formas pura e fromJSON (alvos de 1 min cortados em 1m0s).
Com output vazio, a expressão vira passo/job sem limite, não erro (um passo de 70 s rodou inteiro). Isso importa: o backend roda com if: always() mesmo se o changes falhar, e sem o fallback o teto sumiria. Por isso o || 30 / || 40. Com fallback, cortou em 1m0s.

Testes

tests/ci-config: 98 passam. Novos: padrão 30/40, 45 → 55 com motivo, teto do job ≥ passo + folga, sem motivo / motivo curto / valor menor reprova, padrão explícito não exige motivo, limites e tipo (4, 91, texto, booleano, negativo), não é input, e o ci.yml usa os outputs e os publica. O teste existente dos tetos (test_servicos_efemeros_timeouts) foi atualizado para o desenho com fallback e confere que os fallbacks são 30/40. As outras 7 pastas de teste passam; hub-issue-sync não se aplica (PR fechado sem merge). Os testes do ci.yml falham no código antigo (controle).

⚠️ Limites

Não muda nada para nenhum produto até a develop do ci-shared ir à main (pelo /deploy-safe, não por este PR) e o produto passar a declarar a chave. O DANI declara o dele depois, com o motivo.
É folga, não remédio: no run 41415 o pytest terminou 20 s antes do limite do passo e o passo foi morto porque o processo não saiu em ~19 s (causa não identificada: suíte sem folga e/ou saída lenta). Teste pendurado continua sendo pego pelo --timeout por teste.
Não medi se o runner aplica timeout-minutes do job igual ao do passo quando o job inteiro é cortado por outro motivo; medi só o corte pelo valor da expressão.

🤖 Generated with Claude Code

https://claude.ai/code/session_019nhmgPciDjRhb5KSiZrePM

## O que muda `tests_timeout_minutes` no `ci.yml` reusável (INFRA-68520, pedido do Lineu para o CI do DANI). Antes o passo "Testes (completo)" tinha `timeout-minutes: 30` fixo para toda a frota e o job `backend` 40 fixo. - **Chave no ci-config** (não é input do reusável): `tests_timeout_minutes`, padrão **30**, de 5 a 90. Schema, `ci_config.py`, exemplo e README. - **O teto do job sobe junto**: derivado em `ci_config.py` como `tests_timeout_minutes + 10` (`backend_job_timeout_minutes`, padrão 40). Nunca fica menor que passo + folga (teste cobre 5, 30, 60, 90). - **Motivo obrigatório:** valor diferente de 30 (maior **ou menor**) exige `tests_timeout_motivo` com ≥ 10 caracteres, senão o ci-config reprova. Exceção sem motivo é dívida. - `ci.yml`: passo e job leem os outputs do `changes`, com **fallback literal igual ao padrão** (`|| 30`, `|| 40`). ## Medido no runner real (sondas em branch, já removidas) - `timeout-minutes` com expressão é **avaliado** no passo e no job, nas formas pura e `fromJSON` (alvos de 1 min cortados em 1m0s). - Com output **vazio**, a expressão vira passo/job **sem limite**, não erro (um passo de 70 s rodou inteiro). Isso importa: o `backend` roda com `if: always()` mesmo se o `changes` falhar, e sem o fallback o teto sumiria. Por isso o `|| 30` / `|| 40`. Com fallback, cortou em 1m0s. ## Testes `tests/ci-config`: 98 passam. Novos: padrão 30/40, 45 → 55 com motivo, teto do job ≥ passo + folga, sem motivo / motivo curto / valor menor reprova, padrão explícito não exige motivo, limites e tipo (4, 91, texto, booleano, negativo), não é input, e o `ci.yml` usa os outputs e os publica. O teste existente dos tetos (`test_servicos_efemeros_timeouts`) foi atualizado para o desenho com fallback e confere que os fallbacks são 30/40. As outras 7 pastas de teste passam; `hub-issue-sync` não se aplica (PR fechado sem merge). Os testes do ci.yml falham no código antigo (controle). ## ⚠️ Limites - **Não muda nada para nenhum produto até a `develop` do ci-shared ir à `main`** (pelo `/deploy-safe`, não por este PR) e o produto passar a declarar a chave. O DANI declara o dele depois, com o motivo. - É **folga, não remédio**: no run 41415 o pytest terminou 20 s antes do limite do passo e o passo foi morto porque o processo não saiu em ~19 s (causa não identificada: suíte sem folga e/ou saída lenta). Teste pendurado continua sendo pego pelo `--timeout` por teste. - Não medi se o runner aplica `timeout-minutes` do **job** igual ao do passo quando o job inteiro é cortado por outro motivo; medi só o corte pelo valor da expressão. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_019nhmgPciDjRhb5KSiZrePM

tmf-ia added 1 commit

2026-10-05 15:35:38 -03:00

feat(ci): tests_timeout_minutes por produto no ci.yml reusavel, com motivo obrigatorio [INFRA-68520]

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

Details

2724ff299f

O passo 'Testes (completo)' tinha timeout-minutes 30 fixo para toda a frota. O backend do DANI usou 29m37s
(6300 passed) no run 41415 e o passo foi morto 20 s antes de a suite poder sair. Agora o ci-config declara
tests_timeout_minutes (padrao 30, 5 a 90); o teto do job sobe junto (+10, padrao 40, derivado no ci_config.py);
valor diferente de 30 exige tests_timeout_motivo (>= 10 caracteres).

Medido no runner (sondas em branch, removidas): timeout-minutes aceita expressao em passo e job (puro e
fromJSON), e output VAZIO vira passo/job SEM LIMITE, nao erro; por isso o fallback '|| 30' e '|| 40' no ci.yml
(o backend roda com if: always() mesmo se o changes falhar). Testes novos no ci-config e o teste existente dos
tetos atualizado para o desenho com fallback.

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