1

Release Green

github-actions[bot] edited this page 2026-06-25 16:18:08 +00:00

Table of Contents

• Release-Green: mantendo a fila e a release branch verdes
• O problema que isto resolve
• A família (4 peças) — e como cada uma roda à parte
• Solução C — npm run check:release-green (o motor)
• Solução A — /green-prs (a varredura da fila)
• Cadência recomendada
• Relação com o release

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

🌍 View in other languages

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.

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.

🏠 Home

🌍 Languages (40+)

---

🚀 Getting Started

• Setup Guide
• User Guide
• Features
• Quick Start (Docker)
• Electron Desktop App
• Termux (Android)
• PWA Guide

🌐 Providers

• Provider Reference
• All Providers
• Free Tiers
• Kiro Setup

🎯 Routing & Combos

• Auto-Combo
• Reasoning Replay

🗜️ Compression

• Compression Guide
• Compression Engines
• RTK Compression
• Language Packs
• Rules Format

🔌 Integrations

• MCP Server
• A2A Server
• Agent Protocols
• OpenCode Plugin
• Webhooks
• Cloud Agents
• Skills
• Memory
• Evals
• Gamification

🏗️ Architecture

• Architecture Overview
• Codebase Documentation
• Repository Map
• Authorization Guide
• Resilience Guide

🔒 Security

• Guardrails
• Compliance
• Error Sanitization
• Public Credentials
• Route Guard Tiers
• Stealth Guide
• CLI Token Auth

📋 Reference

• API Reference
• CLI Tools
• Environment Variables

🚀 Operations

• VM Deployment
• Fly.io Deployment
• Tunnels Guide
• Proxy Guide
• SQLite Runtime
• Coverage Plan
• Release Checklist

ℹ️ More

• Troubleshooting
• i18n / Translations
• Uninstall
• Contributing
• Comparison vs Alternatives

OmniRoute · Website · npm · Docker Hub