Solução de problemas de conjuntos de regras
Se você não puder executar uma ação em um repositório e quiser saber o motivo, veja os conjuntos de regras ativos direcionados à tag ou ao branch com o qual está trabalhando. Para saber mais, confira Gerenciar conjuntos de regras para um repositório.
Dependendo das regras ativas, talvez seja necessário editar o histórico de commits localmente para efetuar push dos commits para o branch remoto. Por exemplo, se um branch exigir que os commits sejam assinados, você poderá atualizar as configurações de assinatura e usar um rebase interativo no branch local para reescrever o histórico do Git com os commits assinados. Para saber mais, confira Regras disponíveis para conjuntos de regras e Usar rebase do Git na linha de comando.
Se um branch ou uma tag for alvo de regras que restringem os metadados de commits, seus commits poderão ser rejeitados se uma parte dos metadados do commit não corresponder a um determinado padrão. Por exemplo, talvez seja necessário adicionar um número de issue ao início da mensagem do commit ou alterar o nome de um novo branch ou de uma nova tag que você está tentando enviar para o repositório. Se os commits forem rejeitados, você verá uma mensagem informando o padrão ao qual os metadados relevantes precisam corresponder. Assim como acontece com os commits assinados, talvez seja necessário fazer uma nova troca de base para mesclar os commits por squash ou reescrever cada commit individualmente. Para saber mais, confira Regras disponíveis para conjuntos de regras.
Ao utilizar conjuntos de regras de push, no máximo 1000 atualizações de referência são permitidas por push. Se o push exceder esse limite, ele será rejeitado. Para saber mais, confira Criar conjuntos de regras para um repositório.
Além disso, as regras de push aplicam-se aos endpoints "Create a blob", "Create a tree" e "Create or update file contents" na API REST. Confira Pontos de extremidade da API REST para blobs Git, Pontos de extremidade da API REST para árvores Git e Endpoints da API REST para conteúdo de repositório.
Solução de problemas para checagens de status obrigatórias
Ao definir verificações de status, o formato de nome depende do tipo de verificação:
-
**Fluxo de trabalho**: o formato do nome é `<job name>`. -
**Fluxo de trabalho reutilizável**: o formato do nome é `<job name> / <reusable job name>`. -
**Outras verificações**: o formato do nome é `<check name>`.
As verificações de status necessárias não levam em conta os tipos de fluxo de trabalho, matriz ou gatilho de evento.