Skip to main content

Solução de problemas de regras

Saiba como solucionar problemas de conjuntos de regras ao contribuir para um repositório.

Quem pode usar esse recurso?

Os conjuntos de regras estão disponíveis em repositórios públicos com o GitHub Free e o GitHub Free para organizações e em repositórios públicos e privados com o GitHub Pro, o GitHub Team e o GitHub Enterprise Cloud. Para mais informações, confira "Planos do GitHub".

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 obter mais informações, 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 obter mais informações, 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 obter mais informações, confira "Regras disponíveis para conjuntos de regras".

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.

EventoTipos de atividade padrão
pull_requestopened, synchronize, reopened
pull_request_targetopened, synchronize, reopened
merge_groupchecks_requested

Para obter mais informações, 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 obter mais informações, 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:

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 obter mais informações, 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 obter mais informações, confira "Sobre fluxos de trabalho".

Permissões para criar um novo repositório

Para criar um novo repositório quando um fluxo de trabalho de conjunto de regras estiver configurado, verifique se você tem permissões de bypass para seu conjunto de regras. Para obter mais informações, confira "Criar conjuntos de regras para um repositório".

Insights de regra

GitHub não registra insights de regra até que uma solicitação pull request seja mesclada ou haja uma tentativa de mesclagem.

Simultaneidade

Verifique se o fluxo de trabalho do conjunto de regras não usa a configuração de simultaneidade cancel-in-progress. Para obter mais informações sobre a simultaneidade, confira "Usando simultaneidade".