Workflows e botoes - BrunodosSantosVaz/big-bang GitHub Wiki

Workflows e botões da esteira v3

A esteira do Big Bang v3 gera workflows do GitHub Actions divididos entre o núcleo (core/files/.github/workflows) e os perfis especializados (profiles/<perfil>/files/.github/workflows).

Todas as ações com impacto externo ou escrita crítica operam com simulação por padrão (dry_run=true), exigindo que o operador ou o agente forneça confirmação explícita para aplicar alterações reais.


1. Workflows de desenvolvimento contínuo

bb-ci.yml · CI e portão de qualidade

  • Gatilho: push em branches ativas e pull_request apontando para develop ou release/*.
  • O que faz:
    • Executa verificações da stack: lint, análise estática de tipos, suíte de testes unitários e de integração.
    • No modo Flash, executa seletor de testes afetados (bb test --base origin/develop); no modo normal ou em alterações estruturais, roda a suíte completa.
    • Executa os scanners de segurança (Gitleaks para credenciais e ShellCheck para scripts).
    • Executa bb verify para conferir a integridade dos artefatos gerados.
    • Consolida todas as checagens no status check único obrigatório: gate.

bb-controller.yml · Controlador de eventos e reconciliação

  • Gatilho: Eventos nativos do GitHub (issues, issue_comment, pull_request, push), agendamento a cada 30 minutos e workflow_dispatch.
  • O que faz:
    • Transiciona cartões automaticamente por eventos (push → Coding, PR aberto → In Review, merge → Done).
    • Reconcilia cartões do Project contra os recibos oficiais (<!-- bb:receipt -->), revertendo alterações manuais na interface.
    • Detecta travas atômicas vencidas e aplica o marcador stale.

bb-codeql.yml · Análise estática de vulnerabilidades

  • Gatilho: Agendamento semanal e pushes nas branches principais.
  • O que faz: Varredura profunda do código com o GitHub CodeQL para identificar padrões de falhas de segurança.

2. Workflows de ciclo de sprint e tarefas

bb-start-sprint.yml · Botão Start sprint

  • Gatilho: workflow_dispatch.
  • Inputs:
    • dry_run (boolean, default: true): quando verdadeiro, apenas relata as ações planejadas.
  • Quando rodar: Quando os épicos planejados estiverem no estado Ready e o dono tiver aprovado a seleção com approved:selection.
  • O que faz:
    • Cria as sub-issues para cada épico em Selected: teste de aceite (type:test), tarefas de implementação (type:task) e documentação (type:docs).
    • Estabelece as dependências nativas entre as sub-issues.
    • Cria a branch de teste inicial test/<n>-<slug> a partir da develop.
    • Transiciona o épico para In Progress.

bb-create-branches.yml · Botão Create branches

  • Gatilho: workflow_dispatch ou acionamento automático após o merge do PR de teste de aceite.
  • Inputs:
    • epic (string, opcional): número do épico para filtrar a criação.
  • Quando rodar: Após o teste de aceite de um épico ser mesclado na develop, para liberar as branches de implementação das tarefas.
  • O que faz: Cria as branches feature/<n>-<slug> e docs/<n>-<slug> a partir da develop para as tarefas desbloqueadas.

bb-merge-pr.yml · Botão Merge PR

  • Gatilho: workflow_dispatch.
  • Inputs:
    • pr (string, obrigatório): número do Pull Request a mesclar.
  • Quando rodar: Quando o PR tiver revisão independente aprovada (comentário APROVADO), labels de revisão satisfeitas e check gate verde no SHA exato.
  • O que faz:
    • Valida todas as regras do PR (bb pipeline pr-rules).
    • Executa o merge commit na develop ou release/* (rejeita merge direto na main).
    • Fecha a issue correspondente, move o cartão para Done e libera a trava atômica.

3. Workflows de entrega e release

bb-cut-release.yml · Botão Cut release

  • Gatilho: workflow_dispatch.
  • Inputs:
    • dry_run (boolean, default: true): simulação do corte.
    • version (string, opcional): versão explícita X.Y.Z (calculada automaticamente pelos PRs se omitida).
  • Quando rodar: No encerramento da sprint de desenvolvimento, quando as tarefas dos épicos estiverem mescladas na develop.
  • O que faz:
    • Cria o branch de estabilização release/x.y.z a partir da ponta da develop.
    • Cria o Milestone correspondente no GitHub.
    • Adquire a trava atômica de versão e lista os épicos participantes.

bb-candidate.yml.tmpl · Candidata (específico de perfil)

  • Gatilho: push em release/**. Não é botão: a candidata nasce quando a release é cortada ou recebe uma correção.
  • Segurança: o job candidate-ready, que usa o PROJECT_TOKEN, faz checkout da develop (código confiável); a branch da release é só dado (--branch).
  • Quando rodar: Para disponibilizar uma versão candidata para testes de homologação (QA).
  • O que faz:
    • Corta a tag da candidata vX.Y.Z-rc.N.
    • Compila os binários ou constrói a imagem Docker nos ambientes de teste / staging.
    • Executa smoke tests e valida a integridade do pacote.
    • Transiciona os épicos para QA e abre o PR de release para a branch main.

bb-qa-reject.yml · Botão QA reject

  • Gatilho: workflow_dispatch.
  • Inputs:
    • issue (string, obrigatório): número do épico reprovado no QA.
    • reason (string, obrigatório): motivo da reprovação (ex: tests, security, qa).
    • dry_run (boolean, default: true).
  • Quando rodar: Quando um épico falha nos testes de homologação da candidata.
  • O que faz:
    • Registra a reprovação no histórico e move o épico de volta ao estado de correção.
    • Abre uma issue de correção ligada diretamente à branch de release.

bb-publish.yml.tmpl · Botão Publish

  • Gatilho: workflow_dispatch.
  • Inputs:
    • version (string, obrigatório): versão X.Y.Z confirmada.
    • dry_run (boolean, default: true).
  • Quando rodar: Para publicar a versão aprovada em produção.
  • O que faz:
    • Executa bb release gate conferindo todas as travas, flags e candidatas.
    • Bloqueia no ambiente production aguardando a aprovação manual do dono.
    • Mescla a release na branch main.
    • Promove exatamente os mesmos artefatos validados na candidata (sem recompilar).
    • Conclui os épicos (Done), fecha o Milestone e sincroniza a main de volta com a develop.

4. Manutenção e operações

bb-publish-maintenance.yml · Botão Publish maintenance

  • Gatilho: workflow_dispatch.
  • Inputs:
    • pr (string, obrigatório): número do PR de manutenção criado a partir da main.
    • dry_run (boolean, default: true).
  • Quando rodar: Para correções emergenciais ou documentais que não alteram o artefato de execução (maintenance/*).
  • O que faz: Mescla o PR na main e sincroniza a alteração de volta para a develop.

bb-rollback.yml.tmpl · Botão Rollback (perfil deploy)

  • Gatilho: workflow_dispatch.
  • Inputs:
    • target_version (string, obrigatório): versão anterior para restaurar.
    • dry_run (boolean, default: true).
  • Quando rodar: Em caso de falha crítica pós-deploy em produção.
  • O que faz: Aguarda aprovação do ambiente production e executa o rollback para a versão estável anterior.

bb-cleanup.yml · Botão Cleanup

  • Gatilho: Agendamento diário e workflow_dispatch.
  • Inputs:
    • apply (boolean, default: false): quando verdadeiro, realiza a exclusão real.
  • O que faz: Exclui branches mescladas de issues já fechadas, preservando branches protegidas (main, develop, releases e tags) e reporta travas abandonadas.

bb-board-report.yml · Botão Board report

  • Gatilho: Agendamento semanal e workflow_dispatch.
  • O que faz: Emite relatório consolidado com o estado de todos os cartões, bloqueios ativos e métricas de fluxo.

Para entender os requisitos e portões de cada modo de operação, consulte Modos e Quadro único.

⚠️ **GitHub.com Fallback** ⚠️