@andreias.ai · por baixo do capô

Um push acorda uma equipe. Confira as travas.

Entre o seu git push e a produção, o GitHub pode barrar, chamar revisores, testar de novo e pedir aprovação. Só faz isso se estiver configurado. Marque o que o seu repositório já tem.

01CODEOWNERS com dono para ele mesmo

A última linha que casa vence. Deixe o padrão geral em cima e as pastas específicas embaixo, e dê dono ao próprio arquivo.

# .github/CODEOWNERS
*                   @org/plataforma
/src/pagamentos/    @org/pagamentos
/.github/           @org/seguranca

02Workflow que roda na fila

Sem o evento merge_group, a merge queue espera um CI que nunca começa.

on:
  pull_request:
  merge_group:

03Deploy sem chave guardada

Com OIDC, a nuvem troca um token de vida curta emitido para o job. Nada de chave longa nos secrets.

jobs:
  deploy:
    environment: production
    permissions:
      id-token: write
      contents: read

04Regras da main

A main protegida é a primeira estação.

Push direto na main é bloqueado; tudo entra por pull request. Force push e exclusão da main estão bloqueados. Os checks do CI são obrigatórios para o merge.

05Donos e revisão

Revisão de dono só trava o merge se estiver ligada na regra.

Existe um .github/CODEOWNERS e a ordem das linhas foi revisada. O próprio CODEOWNERS e a pasta .github têm dono. "Require review from Code Owners" está ligado na regra da main.

06Fila de merge

A fila testa o seu PR junto com a main atual e com quem está na frente.

A merge queue está ligada para a main. Todo workflow obrigatório escuta o evento merge_group. Os checks exigidos na fila são os mesmos do pull request.

07Deploy

Produção pede uma pessoa no caminho e nenhuma chave guardada.

O ambiente production exige aprovação antes do job rodar. O deploy usa OIDC (id-token: write) em vez de chave de nuvem nos secrets. A confiança na nuvem está restrita ao repositório e ao ambiente certos.