Skip to main content
Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais atualizadas, acesse a documentação em inglês.

Solução de problemas de verificações de status necessárias

Você pode verificar erros comuns e resolver problemas com as verificações de status necessárias.

Branches protegidos estão disponíveis em repositórios públicos com GitHub Free e GitHub Free para organizações e em repositórios públicos e privados com GitHub Pro, GitHub Team, GitHub Enterprise Cloud e GitHub Enterprise Server.

Se você tiver uma verificação e um status com o mesmo nome e selecionar esse nome como uma verificação de status obrigatória, a verificação e o status serão obrigatórios. Para obter mais informações, confira "Verificações".

Depois que você habilitar as verificações de status solicitadas, seu branch pode precisar estar atualizado com o branch de base antes da ação de merge. Isso garante que o branch foi testado com o código mais recente do branch base. Se o branch estiver desatualizado, você precisará fazer merge do branch base no seu branch. Para obter mais informações, confira "Sobre branches protegidos".

Observação: você também pode atualizar o branch com o branch base usando a troca de base do Git. Para obter mais informações, confira "Sobre a troca de base do Git".

Não será possível fazer push de alterações locais em um branch protegido enquanto todas as verificações de status obrigatórias não forem aprovadas. Sendo assim, você receberá uma mensagem de erro semelhante à mostrada a seguir.

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing

Observação: as solicitações de pull que estão atualizadas e são aprovadas nas verificações de status obrigatórias podem ser mescladas localmente e enviadas por push para o branch protegido. Isso pode ser feito sem verificações de status em execução no próprio commit de merge.

Conflitos entre o título do commit e o commit de merge do teste

Por vezes, os resultados das verificações de status para o commit de mescla teste e o commit principal entrarão em conflito. Se o commit de merge de testes tem status, o commit de merge de testes deve passar. Caso contrário, o status do commit principal deve passar antes de você poder mesclar o branch. Para obter mais informações sobre os commits de mesclagem de teste, confira "Pulls".

Manipulação ignorada, mas verificações necessárias

Observação: se um fluxo de trabalho for ignorado devido à filtragem de caminho, à filtragem de branch ou a uma mensagem de commit, as verificações associadas a esse fluxo de trabalho permanecerão em um estado "Pendente". Uma solicitação de pull que exija que essas verificações sejam bem-sucedidas não poderá ser mesclada.

Se um trabalho em um fluxo de trabalho for ignorado devido a um condicional, ele relatará seu status como "Êxito". Para obter mais informações, consulte Como ignorar execuções de fluxo de trabalho e Como usar condições para controlar a execução do trabalho.

Exemplo

O exemplo a seguir mostra um fluxo de trabalho que requer um status de conclusão "Êxito" para o trabalho build, mas o fluxo de trabalho será ignorado se a solicitação de pull não alterar nenhum arquivo no diretório scripts.

name: ci
on:
  pull_request:
    paths:
      - 'scripts/**'
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]
    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Devido à filtragem de caminho, uma solicitação de pull que altera apenas um arquivo na raiz do repositório não disparará esse fluxo de trabalho e não poderá ser mesclada. Na solicitação de pull, você verá "Aguardando status ser relatado".

Você pode corrigir isso criando um fluxo de trabalho genérico, com o mesmo nome, que retornará verdadeiro em qualquer caso semelhante ao fluxo de trabalho abaixo:

name: ci
on:
  pull_request:
    paths-ignore:
      - 'scripts/**'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: 'echo "No build required"'

Agora, as verificações sempre serão aprovadas sempre que alguém enviar uma solicitação de pull que não altere os arquivos listados em paths no primeiro fluxo de trabalho.

Observações:

  • Garanta que a chave name e o nome do trabalho obrigatório sejam os mesmos nos dois arquivos de fluxo de trabalho. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".
  • O exemplo acima usa GitHub Actions, mas esta solução alternativa também se aplica a outros provedores de CI/CD que se integram a GitHub.

Verificações de status de fontes inesperadas obrigatório

Também é possível que um branch protegido exija uma verificação de status de um GitHub App específico. Se você vir uma mensagem parecida com a seguinte, você deverá verificar se a verificação listada na caixa de merge foi definida pelo aplicativo esperado.

Required status check "build" was not set by the expected GitHub App.