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".
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 obter mais informações, 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 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:
- Adicionar uma condicional ao arquivo de fluxo de trabalho, como
if: true. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions". - Desativar completamente as ações no repositório de origem. Para obter mais informações, confira "Gerenciando as configurações do GitHub Actions para um repositório".
- Desativar o fluxo de trabalho individual no repositório de origem. Para obter mais informações, 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 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 "Controlar a simultaneidade de fluxos de trabalho e trabalhos".