As verificações de status se baseiam em processos externos, como compilações de integração contínua, que são executados para cada push que você faz em um repositório. Você pode ver o estado pendente, aprovado ou com falha das verificações de status ao lado de commits individuais na sua solicitação de pull.
Qualquer pessoa com permissão de gravação em um repositório pode configurar o estado de qualquer verificação de status no repositório.
É possível ver o estado geral do último commit em um branch na página de branches do seu repositório ou na lista de pull requests do seu repositório.
Se as verificações de status forem necessárias para um repositório, as verificações de status necessárias devem passar antes que você possa fazer merge do seu branch no branch protegido. Para saber mais, confira Sobre branches protegidos.
Observação: um trabalho ignorado relatará seu status como "Êxito". Ele não impedirá a mesclagem de uma solicitação de pull, mesmo que seja uma verificação necessária.
Tipos de verificação de status no GitHub
Há dois tipos de verificação de status no GitHub:
- Verificações
- Status do commit
As verificações são diferentes dos status de confirmação porque fornecem anotações de linha, mensagens mais detalhadas e estão disponíveis somente para uso com GitHub Apps.
Note
As GitHub Actions geram verificações, e não status de commit, quando os fluxos de trabalho são executados.
Os proprietários de organizações e usuários com acesso push a um repositório podem criar verificações e status de confirmação com a API do GitHub. Para saber mais, confira Pontos de extremidade da API REST para verificações e Pontos de extremidade da API REST para status de commits.
Verificações
Quando as verificações são configuradas em um repositório, as solicitações em pull têm uma guia Verificações na qual é possível realizar a exibição da saída detalhada da compilação das verificações e executar novamente as verificações com falha.
Note
A guia Checks será preenchida para pull requests se você configurar verificações, e não status de commit, para o repositório.
Quando uma linha específica em um commit causar uma falha em uma verificação, você verá os detalhes sobre a falha ou o aviso ao lado do código relevante na guia Arquivos da solicitação de pull.
Navegue entre os resumos das verificações de vários commits em uma solicitação de pull usando o menu suspenso do commit na guia Verificações.
Ignorar e solicitar verificações para commits individuais
Quando um repositório é definido para solicitar verificações por pushes automaticamente, você pode optar por ignorar as verificações para um commit individual do qual fez push. Quando um repositório não é definido para solicitar verificações para pushes automaticamente, você pode solicitar verificações para um commit individual enviado por push. Para saber mais sobre essas configurações, confira Pontos de extremidade da API REST para pacotes de verificação.
Você pode ignorar as execuções de fluxo de trabalho disparadas pelos eventos push e pull_request incluindo um comando na mensagem de commit. Para saber mais, confira Ignorar execuções de fluxo de trabalho
Como alternativa, para ignorar ou solicitar todas as verificações do commit, adicione uma das seguintes linhas de trailer ao fim da mensagem de commit:
-
Para ignorar as verificações de um commit, digite sua mensagem de commit e uma descrição curta e significativa das alterações. Após a descrição do commit, antes das aspas de fechamento, adicione duas linhas vazias seguidas de
skip-checks: true:$ git commit -m "Update README > > skip-checks: true" -
Para solicitar verificações para um commit, digite sua mensagem de commit e uma descrição curta e significativa das alterações. Após a descrição do commit, antes das aspas de fechamento, adicione duas linhas vazias seguidas de
request-checks: true:$ git commit -m "Refactor usability tests > > request-checks: true"
Por padrão, o Git remove automaticamente novas linhas consecutivas. Para deixar a mensagem de commit exatamente como você a inseriu, use a opção --cleanup=verbatim no commit. Para obter mais informações, confira --cleanup=<mode> na documentação do Git.
Status e conclusões de verificação
As verificações podem ter muitos status diferentes. Os status descrevem o estado de uma verificação desde quando ela é criada até quando é concluída. Alguns status não podem ser definidos manualmente e são reservados para GitHub Actions. Quando uma verificação tem um status de completed, ela tem uma conclusão. A conclusão descreve o resultado da verificação. Todos os status e conclusões de verificação possíveis estão listados abaixo.
| Status | Descrição | GitHub Actions somente? |
|---|---|---|
completed | A execução da verificação foi concluída e tem uma conclusão (veja abaixo). | Não |
expected | A execução da verificação está aguardando um status ser relatado. | Sim |
failure | Falha na execução de verificação. | Não |
in_progress | A execução da verificação está em andamento. | Não |
pending | A execução da verificação está na frente da fila, mas o limite de simultaneidade baseado em grupo foi atingido. | Sim |
queued | A execução da verificação foi enfileirada. | Não |
requested | A execução da verificação foi criada, mas não foi enfileirada. | Sim |
startup_failure | O conjunto de verificação falhou durante a inicialização. Esse status não se aplica a execuções de verificação. | Sim |
waiting | A execução da verificação está aguardando que uma regra de proteção de implantação seja atendida. | Sim |
| Conclusão | Descrição |
|---|---|
action_required | A execução da verificação forneceu as ações necessárias após sua conclusão. Para saber mais, confira Como usar a API REST para interagir com verificações. |
cancelled | A execução da verificação foi cancelada antes de ser concluída. |
failure | Falha na execução de verificação. |
neutral | A execução da verificação foi concluída com um resultado neutro. Isso é tratado como um êxito para verificações dependentes em GitHub Actions. |
skipped | A execução da verificação foi ignorada. Isso é tratado como um êxito para verificações dependentes em GitHub Actions. |
stale | A execução da verificação foi marcada como obsoleta pelo GitHub porque demorou muito. |
success | A execução da verificação foi concluída com sucesso |
timed_out | A execução da verificação atingiu o tempo limite. |
Retenção de verificações
A GitHub retém os dados de verificação por 400 dias. Após esses 400 dias, os dados são arquivados. Dez dias após o arquivamento, os dados são excluídos permanentemente.
Para mesclar uma solicitação de pull com verificações necessárias e arquivadas, execute novamente as verificações.