Solução de problemas de regras

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 uma troca de base interativa 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 uma tag ou um branch for direcionado por regras que restringem os metadados de commits, seus commits poderão ser rejeitados se uma parte dos metadados do commit não corresponder a determinado padrão. Por exemplo, talvez seja necessário adicionar um número de problema ao início da mensagem do commit ou alterar o nome de uma nova tag ou de um novo branch do qual você está tentando efetuar push 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.

Solucionando problemas dos fluxos de trabalho de conjuntos de regras

Os fluxos de trabalho do conjunto de regras podem ser configurados no nível da organização para exigir que os fluxos de trabalho passem antes de mesclar solicitações de pull request. Para obter mais informações, confira "Criar conjuntos de regras para repositórios na sua organização".

Fluxos de trabalho do conjunto de regras para solicitações pull request abertas

Se você criar uma regra enquanto uma solicitação pull request estiver aberta, o fluxo de trabalho necessário não será executado automaticamente. Para acionar o fluxo de trabalho necessário, envie um novo commit, atualize sua ramificação ou feche e reabra a solicitação pull request.

Eventos de fluxo de trabalho do conjunto de regras com suporte

Os fluxos de trabalho do conjunto de regras oferecem suporte usando os eventos pull_request, pull_request_target e merge_group. Como resultado, você deve especificar um ou mais desses eventos na seção on: do fluxo de trabalho para que o fluxo de trabalho seja executado por um conjunto de regras.

Todos os filtros especificados para os eventos com suporte são ignorados - por exemplo, branches, branches-ignore, paths, types e assim por diante. O fluxo de trabalho é acionado apenas e sempre pelos tipos de atividade padrão dos eventos com suporte.

Evento	Tipos de atividade padrão
`pull_request`	`opened`, `synchronize`, `reopened`
`pull_request_target`	`opened`, `synchronize`, `reopened`
`merge_group`	`checks_requested`

Para saber mais, confira Eventos que disparam fluxos de trabalho.

Os fluxos de trabalho do conjunto de regras não são executados em eventos acionados pelo GITHUB_TOKEN. Para saber mais, confira Autenticação automática de token.

Bloqueando a criação de repositórios

Um fluxo de trabalho obrigatório também pode impedir que alguém crie um repositório, já que um fluxo de trabalho não pode ser executado em um repositório que está sendo inicializado. Para contornar isso, o conjunto de regras precisa ter "Avaliar" como o status de imposição ou alguém com permissões de bypass precisa criar o repositório e ignorar a proteção de ramificação.

Para obter mais informações sobre os status de imposição e o modo “Avaliar”, confira Criar conjuntos de regras para um repositório.

Para saber mais sobre como desviar de permissões, confira Sobre branches protegidos.

Metas de ramificação em um conjunto de regras

Verifique se o fluxo de trabalho do conjunto de regras não tem como meta todas as ramificações no repositório. Ele só deve ter como meta ramificações onde todas as alterações na ramificação são executadas por solicitações pull request.

Diretório com suporte

Verifique se o arquivo de fluxo de trabalho existe no diretório .github/workflows. Se desejar executar um fluxo de trabalho de conjunto de regras em eventos pull_request em um repositório que não seja o repositório de origem, você poderá executar qualquer uma das seguintes ações:

Adicionar uma condicional ao arquivo de fluxo de trabalho, como if: true. Para saber mais, confira Sintaxe de fluxo de trabalho para o GitHub Actions.
Desativar completamente as ações no repositório de origem. Para saber mais, confira Gerenciando as configurações do GitHub Actions para um repositório.
Desativar o fluxo de trabalho individual no repositório de origem. Para saber mais, confira Desabilitar e habilitar um fluxo de trabalho.

Usando o gatilho `merge_group`

Se o seu repositório usa o GitHub Actions para realizar verificações necessárias ou se você exige fluxos de trabalho por meio de conjuntos de regras da organização em solicitações pull em seu repositório, é necessário atualizar os fluxos de trabalho para incluir o evento merge_group como um gatilho adicional. Caso contrário, as verificações de status não serão disparadas quando você adicionar uma solicitação de pull a uma fila de mesclagem. A mesclagem falhará, pois o verificação de status obrigatória não será relatada. O evento merge_group é separado dos eventos pull_request e push.

Permissões do repositório de origem

Verifique se as permissões do repositório de origem estão definidas como "Acessível a partir de repositórios na organização ORGANIZATION NAME".

Para saber mais, confira Gerenciando as configurações do GitHub Actions para um repositório.

Configurações de privacidade do repositório de origem

Verifique se o arquivo de fluxo de trabalho do conjunto de regras está em um repositório de origem que tenha as configurações de privacidade iguais ou menos restritivas do que os repositórios nos quais você deseja executá-lo. Especificamente, um fluxo de trabalho público pode ser executado em qualquer repositório na sua organização, um fluxo de trabalho interno pode ser executado em repositórios internos e privados e um fluxo de trabalho privado pode ser executado em repositórios privados. Para saber mais, confira Sobre fluxos de trabalho.

Quem pode usar esse recurso?

Neste artigo