Remover aprovação de deploy em produção

TLDR: O CI deixa de sincronizar reviewers do GitHub Environment production; qualquer pessoa passa a subir tag em produção sem aprovação de owner. owners continua existindo, servindo apenas ao RBAC do cluster.

Contexto

Hoje, subir uma tag em produção em qualquer app da org trava esperando aprovação manual de um owner. Remover a rule pela UI do GitHub não resolve: ela volta sozinha no próximo merge que tocar config/access.yml.

A cadeia que recria a rule:

config/access.yml projects.<projeto>.owners ↓ push em main (paths filter inclui config/access.yml) .github/workflows/infra.yml — job sync-reviewers run: sync-environment-reviewers.sh config/access.yml ibft-corp ↓ .project/shell/tasks/ci/github/sync-environment-reviewers.sh PUT repos/ibft-corp/<app>/environments/production {"reviewers":[{"type":"User","id":<id>}]} ↓ protection rule required_reviewers recriada em cada app

O campo owners tem dois consumidores independentes:

A decisão é desfazer só o primeiro. O RBAC do cluster continua como está — ninguém perde exec nem port-forward em produção.

Um detalhe do script explica por que a limpeza precisa ser explícita: quando a lista de owners está vazia ele executa continue e pula o repo, em vez de zerar os reviewers. Ou seja, parar de sincronizar não desfaz o que já foi escrito — os repos que hoje têm a rule precisam ser limpos uma vez, na mão.

Estado levantado em 2026-09-21 — 7 dos 12 apps ainda têm a rule ativa:

Os outros 5 (onion-backend, trgclub-api, trgclub-web, citrg-api, checkout-api) já foram limpos manualmente e voltariam no próximo merge de config/access.yml.

Objetivos

• Qualquer pessoa pode subir tag em produção, em qualquer app da org, sem aprovação de owner
• O gate não volta sozinho em nenhum merge futuro
• owners continua alimentando o RBAC do cluster, sem perda de exec ou port-forward
• Nenhum script órfão fica no repositório

Fora de escopo

• CODEOWNERS. O step Sync CODEOWNERS do mesmo job continua intacto — aprovação de PR nos devops.repos não muda.
• RBAC do cluster. gen-access-tfvars.sh, os RoleBindings e o stack de kubernetes não são tocados.
• Impedir readição manual. Nada impede um admin de recriar a rule pela UI do GitHub depois. A alternativa (um script que zera reviewers a cada run) foi considerada e descartada: mantém maquinaria rodando só para desfazer configuração.
• ibft-corp/pipelines. O deploy.yml@v1 declara environment: no job, o que é correto e necessário para o rastreamento de deployments — não é a causa e não muda.

Mudanças

ibft-corp/infrastructure

ibft-corp/commons

Operação única

Limpar a rule nos 7 apps da tabela de contexto:

bash for r in onion-mobile citrg-memberarea checkout-web gateway messenger-api marketing nectar-charges; do echo '{"wait_timer":0,"reviewers":[],"deployment_branch_policy":null}' \ | gh api -X PUT "repos/ibft-corp/$r/environments/production" --input - --silent done

Ordem importa: limpar depois do merge, para não correr o risco de um merge intermediário reescrever a rule.

Prova

bash for r in onion-backend onion-mobile trgclub-api trgclub-web citrg-api citrg-memberarea \ checkout-api checkout-web gateway messenger-api marketing nectar-charges; do n=$(gh api "repos/ibft-corp/$r/environments" \ -q '[.environments[].protection_rules[]? | select(.type=="required_reviewers")] | length') echo "$r: $n" done

Esperado: 0 em todos.

Documentação

• .project/docs/guides/access.md — atualizado nesta mudança (ver tabela de Mudanças)
• config/access.yml — comentários de cabeçalho atualizados; o arquivo é a fonte de verdade e seus comentários são a documentação de primeira linha
• Esta spec passa a ser a referência da decisão; a spec Configuração centralizada de acesso permanece válida no que diz respeito a RBAC e CODEOWNERS