Spaces:
Runtime error
Runtime error
File size: 6,006 Bytes
cd8bd0a | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 | ---
title: "Release-Green — fila e release branch verdes"
---
# Release-Green: mantendo a fila e a release branch verdes
## O problema que isto resolve
O **gate completo** (`.github/workflows/ci.yml` — unit shards, vitest, ratchets,
`package-artifact`, SonarQube, E2E) roda **apenas na release PR** (PR → `main`). PRs para
`release/**` recebem só as **fast-gates** (`quality.yml`: testes TIA-impactados + typecheck +
lint). Consequência: reds se acumulam silenciosamente na release branch e **explodem em camadas
de ~40 min** no momento do release, uma de cada vez.
A "família release-green" existe para **antecipar** esses reds — validar o equivalente ao gate
completo **localmente / fora do release**, a qualquer momento, para que a release PR já nasça
verde na primeira CI.
> **Princípio inegociável:** nada disto bloqueia o contribuidor. Não adicionamos um required
> check que falhe o PR dele. O **drift** (ratchets) é do mantenedor rebaselinar no release —
> nunca uma preocupação do contribuidor. Nenhuma peça **fecha** um PR (roubo de crédito) nem
> **enfraquece** um teste para passar.
## A família (4 peças) — e como cada uma roda à parte
| Peça | O que é | Quando rodar | Escopo |
| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | ------------------------------------ |
| **`/green-prs`** (Solução A) | Varredura sob demanda do mantenedor sobre a **fila de PRs abertos** | **À parte, periódico** — e principalmente **antes** de um `/generate-release` | Fila inteira de PRs → `release/**` |
| **`/validate-release-green`** (Solução C — `npm run check:release-green`) | Motor de validação: reproduz o gate completo contra uma branch OU um merge-candidato | À parte, a qualquer momento | Uma branch específica ou um PR-merge |
| **`/babysit <PR#>`** | Conduz a **CI ao vivo** de **um** PR até o verde | À parte, por PR | Um PR |
| **`nightly-release-green.yml`** (Solução D) | Workflow noturno automático; abre issue em HARD red | Automático (cron) | A release branch ativa |
**Resposta curta à pergunta "é só para release?":** **não.** O `/green-prs` foi desenhado para
rodar **de tempos em tempos, entre releases**. Rodar à parte é o uso normal — o release é apenas
o momento em que rodá-lo dá mais retorno.
## Solução C — `npm run check:release-green` (o motor)
Reproduz a validação release-equivalente contra a árvore de trabalho atual e classifica cada red:
- **HARD** (typecheck, lint errors, unit, vitest, db-rules, public-creds, opcional
`package-artifact`) → **defeito real**; `exit 1`. Conserta-se na branch de origem (TDD, Rule #18).
- **DRIFT** (eslint **warnings**, cognitive-complexity, file-size) → drift de ratchet acumulado no
ciclo, **não é culpa do contribuidor**; é só reportado e **rebaselinado pelo mantenedor no
release**. Drift **nunca** muda o exit code — então nunca bloqueia ninguém.
```bash
npm run check:release-green # branch atual (working tree)
node scripts/quality/validate-release-green.mjs --json # saída estruturada
node scripts/quality/validate-release-green.mjs --quick # pula unit+vitest (só drift+typecheck+lint)
node scripts/quality/validate-release-green.mjs --with-build # inclui package-artifact (lento)
```
Diagnostica e **reporta** apenas (sem auto-fix). A orquestração de fix-to-green vive no
`/green-prs` e no `/review-prs`.
## Solução A — `/green-prs` (a varredura da fila)
Procedimento (resumo — ver a skill `green-prs` para o detalhe):
1. **Inventariar** a fila de PRs abertos contra a release branch ativa.
2. **Triar** cada PR (viável / reject-worthy / needs-author) — reject/needs-author são
**reportados, não fechados** (o dono decide).
3. Para cada viável, em **worktree isolado** (Rule #19), trazer o PR ao tip da release e rodar
`npm run check:release-green`:
- **HARD** → consertar **na branch do contribuidor** via coautoria (mantém o "Merged" do autor),
re-rodar até zerar os HARD.
- **DRIFT** → deixar; é rebaselinado no release.
4. **Reportar** uma tabela PR × (verdict, HARD reds, fixado?, DRIFT, release-green agora?).
Pode **preparar** a fila sem mergear; só mergeia quando explicitamente pedido — e nunca fecha PR.
## Cadência recomendada
- Rode **`/green-prs` periodicamente** (ex.: semanalmente) e **sempre antes de um
`/generate-release`**.
- Deixe o **`nightly-release-green.yml`** (Solução D) como sinal contínuo: quando ele abrir issue
de HARD red, é hora de uma varredura.
- Use **`/validate-release-green`** ad-hoc para checar uma branch ou um merge-candidato pontual.
- Use **`/babysit <PR#>`** quando um PR específico precisa ser conduzido ao verde na CI ao vivo.
## Relação com o release
- `/generate-release` chama a validação na **Fase 0 (pré-flight)**: rebaselina o DRIFT e conserta
o HARD antes de abrir a release PR.
- `/review-prs` usa o gate release-green no passo de decisão de merge (verde-antes-de-merge).
O objetivo de todas as peças é o mesmo: **a release PR verde na primeira CI**, em vez de surfar
reds em camadas de 40 min no dia do release.
|