Escolha onde a Taiga espera por uma decisão

Separe quatro decisões

O serviço fictício de equipamentos tem quatro decisões diferentes: aceitar o plano, executar o build, fazer merge da alteração e fazer seu deployment. Não trate uma única opção como autorização para as quatro.

Antes de mudar a autonomia, inspecione o que o pipeline do repositório faz após o merge. Se o merge na branch de trabalho iniciar um deployment, um merge automatizado também poderá iniciar esse fluxo existente.

Decida se o plano espera

A configuração de produto Build on its own by default controla se um plano concluído segue para o build ou espera aprovação. Desative-a quando os planos precisarem primeiro de uma decisão humana.

A configuração Build on its own de uma iniciativa pode mudar esse comportamento para aquela iniciativa. Inspecione a configuração padrão e qualquer escolha específica antes de colocar trabalho na fila.

Approve inicia o build em nome da pessoa que aprova, sujeito às permissões atuais dela. Um plano que falha não inicia build. A automação do build, sozinha, não autoriza o merge do pull request resultante.

Entenda a hierarquia do merge

O merge autônomo é controlado separadamente e fica desativado até ser habilitado. A integração documentada suporta GitHub, incluindo GitHub Enterprise.

Um limite desativado na organização ou na factory não pode ser substituído por um nível inferior. Uma configuração padrão desativada no produto é diferente: uma iniciativa pode ativar seu próprio merge se os limites superiores permitirem.

Para o serviço de equipamentos, mantenha explícito o escopo inicial. Uma iniciativa de consequências limitadas pode ter uma escolha diferente de uma alteração nos controles de acesso de funcionários, dentro dos limites permitidos.

Torne obrigatórias as revisões exigidas

A Taiga pergunta ao provedor de controle de versão se o pull request pode receber merge. A proteção da branch determina as verificações, revisões e outras condições obrigatórias. O merge autônomo não ignora essas regras.

Se uma revisão automatizada precisa bloquear o merge, torne seu resultado uma verificação de status obrigatória pela configuração suportada do repositório. Um resultado consultivo não vira obrigatório apenas porque você espera que seja.

Verifique também as aprovações humanas exigidas. Uma verificação verde não substitui uma aprovação exigida pela política. Confirme as regras na branch real de destino.

Interprete um merge interrompido

Leia o motivo na iniciativa. Uma verificação pendente, aprovação ausente, conflito e plano incompleto exigem respostas diferentes. A Taiga também interrompe o merge autônomo quando correções alteram os critérios que fizeram verificações com falha passar. Revise essa alteração diretamente.

Não remova uma verificação obrigatória apenas porque ela impede o avanço. Se a verificação nunca informar resultado, corrija sua configuração ou use o processo autorizado de políticas. Inspecione o commit atual após qualquer correção.

Mantenha a autorização de deployment separada

O GitHub App da Taiga executa um merge autônomo e fica registrado como responsável pelo merge. O pipeline do repositório mantém seu comportamento existente de deployment.

Neste cenário, o merge faz deployment em staging. A produção ainda exige a decisão e as evidências de produção da organização. Confirme que o pipeline impõe essa separação. Continue com revisão da entrega.