Regras de solução de problemas

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.

As verificações de status não são indexadas para conjuntos de regras definidos acima do nível do repositório. Insira manualmente o nome exato da verificação esperado.

Para conjuntos de regras no modo de avaliação, uma verificação de status será executada na ramificação de destino, mas não será necessária para ser aprovada.

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 ou empresa para exigir que os fluxos de trabalho passem antes de mesclar pull requests. Para saber mais, confira Criar conjuntos de regras para repositórios na sua organização.

Fluxos de trabalho do conjunto de regras para solicitações de pull 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 Usar GITHUB_TOKEN para autenticação em fluxos de trabalho.

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 aplicaçã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 os 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 somente deve aplicar-se a ramificações onde todas as mudanças são feitas por meio de pull requests.

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 configurações de 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 configurações de 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 Fluxos de trabalho.

Quem pode usar esse recurso?

Neste artigo