feat(gates): versionCode Android crescente no PR (head vs base) [INFRA-68854] #70

Merged
tmf-ia merged 1 commit from feat/INFRA-68854-version-code-android into develop 2026-10-08 22:06:51 -03:00
Owner

O quê [INFRA-68854, item versionCode]

Pela decisão do operador de 08/10 (INFRA-68856, Opção A), o versionCode Android passa a ser gate de PR: compara head com base. O item saiu da Fase 3 e entrou na Fase 1. A sessão ORG, dona do ci-shared hoje, repassou este item à sessão tmf_ia.

Como

  • Passo novo no job gates: "Android: versionCode crescente". O gates já está no needs do ci-ok, então não há job novo, nem mudança no agregador ou nas REGRAS do avaliar_gate_final.py.
  • scripts/conferir-version-code.sh (só bash + git, mesmo método do conferir-release.sh): varre todos os app/build.gradle(.kts) versionados (Fina e Priceshow têm dois apps) e busca a base sozinho, mesmo com checkout raso.
Situação Resultado
versionCode do head < base barra
versionName literal mudou sem subir o versionCode barra
versionCode computado (não literal) barra: desconhecido não é verde
base ilegível barra
PR para main muda o módulo do app sem subir aviso (::warning::), não barra
app novo só confere o literal
repo sem app Android NÃO SE APLICA, dentro do passo (sai 0, nunca if: de job)

Por que a regra de release é aviso: medi o script contra os produtos reais. Na forma bloqueante, ela barraria hoje o próximo release de HelpCor, Fina e tmf9, porque o Android mudou sem bump. A decisão aprovada fala em "monotônico"; exigir bump a cada release que toca o Android vai além dela, e nem todo release vai para a loja. Torná-la bloqueante fica para o operador.

  • ci.yml: decisão versioncode no "Gate — o que se aplica?" (só em PR), zerada no modo nenhum; o ci-shared é buscado quando aplica.
  • docs/guia-de-adocao.md: seção nova.

Prova

  • tests/version-code: 17 testes, com origin bare de verdade e clone (inclusive raso). Cada "passa" tem um controle que reprova. A amarração do workflow é testada: passo no gates, if: no passo, gates sem if: de job que vire skipped, gates no needs do ci-ok.
  • Todas as suítes de tests/*/: verdes.
  • Contra os produtos reais (clones temporários), PR develop→develop: DANI, HelpCor, Fina (2 apps), Priceshow (2 apps) e tmf9 passam.

Vai para develop e entra no release seguinte do ci-shared, sem empilhar no #69.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WvS8ZjH9fTnKcnuWXPUyDm

## O quê [INFRA-68854, item versionCode] Pela decisão do operador de 08/10 (INFRA-68856, Opção A), o `versionCode` Android passa a ser **gate de PR**: compara head com base. O item saiu da Fase 3 e entrou na Fase 1. A sessão ORG, dona do ci-shared hoje, repassou este item à sessão tmf_ia. ## Como - **Passo novo no job `gates`**: "Android: versionCode crescente". O `gates` já está no `needs` do `ci-ok`, então não há job novo, nem mudança no agregador ou nas REGRAS do `avaliar_gate_final.py`. - **`scripts/conferir-version-code.sh`** (só bash + git, mesmo método do `conferir-release.sh`): varre todos os `app/build.gradle(.kts)` versionados (Fina e Priceshow têm dois apps) e busca a base sozinho, mesmo com checkout raso. | Situação | Resultado | |---|---| | `versionCode` do head < base | **barra** | | `versionName` literal mudou sem subir o `versionCode` | **barra** | | `versionCode` computado (não literal) | **barra**: desconhecido não é verde | | base ilegível | **barra** | | PR para `main` muda o módulo do app sem subir | **aviso** (`::warning::`), não barra | | app novo | só confere o literal | | repo sem app Android | **NÃO SE APLICA**, dentro do passo (sai 0, nunca `if:` de job) | **Por que a regra de release é aviso:** medi o script contra os produtos reais. Na forma bloqueante, ela barraria hoje o próximo release de **HelpCor, Fina e tmf9**, porque o Android mudou sem bump. A decisão aprovada fala em "monotônico"; exigir bump a cada release que toca o Android vai além dela, e nem todo release vai para a loja. Torná-la bloqueante fica para o operador. - `ci.yml`: decisão `versioncode` no "Gate — o que se aplica?" (só em PR), zerada no modo `nenhum`; o ci-shared é buscado quando aplica. - `docs/guia-de-adocao.md`: seção nova. ## Prova - `tests/version-code`: 17 testes, com `origin` bare de verdade e clone (inclusive raso). Cada "passa" tem um controle que reprova. A amarração do workflow é testada: passo no `gates`, `if:` no passo, `gates` sem `if:` de job que vire skipped, `gates` no `needs` do `ci-ok`. - Todas as suítes de `tests/*/`: verdes. - Contra os produtos reais (clones temporários), PR develop→develop: DANI, HelpCor, Fina (2 apps), Priceshow (2 apps) e tmf9 passam. Vai para `develop` e entra no release seguinte do ci-shared, sem empilhar no #69. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01WvS8ZjH9fTnKcnuWXPUyDm
feat(gates): versionCode Android crescente no PR (head vs base) [INFRA-68854]
All checks were successful
PR checks (ci-shared) / testes (pull_request) Successful in 3m17s
f3904b95dc
Decisão do operador (08/10, INFRA-68856 Opção A): versionCode é gate de PR, movido da Fase 3
para a Fase 1. Passo novo no job gates (já no needs do ci-ok: sem job novo, sem mexer no
agregador nem nas REGRAS do avaliar_gate_final.py).

- scripts/conferir-version-code.sh: todos os app/build.gradle(.kts) versionados; barra versionCode
  menor que a base, versionName mudado sem subir o code e code não literal; release para main que
  muda o módulo sem subir = AVISO (medido: barraria HelpCor, Fina e tmf9 hoje); sem app = NÃO SE
  APLICA de dentro do passo (sai 0, nunca if: de job); base ilegível = reprova
- ci.yml: decisão versioncode no Gate (só em PR), zerada no modo nenhum, ci-shared buscado
- tests/version-code: 17 testes (origin bare + clone, inclusive raso) + amarração do workflow
- docs/guia-de-adocao.md: seção do gate

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WvS8ZjH9fTnKcnuWXPUyDm
tmf-ia merged commit 3ca7982c41 into develop 2026-10-08 22:06:51 -03:00
Sign in to join this conversation.
No reviewers
No labels
seguranca
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
TMF/ci-shared!70
No description provided.