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 recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.
O GitHub AE está atualmente sob versão limitada. Entre em contato com nossa Equipe de Vendas para saber mais.

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.

Os branches protegidos estão disponíveis em repositórios internos e privados comGitHub AE, 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, consulte "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, consulte "Sobre branches protegidos".

Observação: também é possível atualizar o seu branch com o branch base usando o rebase do Git. Para obter mais informações, consulte "Rebase no 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 a esta.

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

Observação: as pull requests que são atualizadas e passam nas verificações de status obrigatórias podem sofrer merge 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 commits de merge de teste, consulte "Pulls".

Branch com commits de mescla conflitantes

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

Às vezes, uma verificação de status exigida é ignorada nos pull requests devido ao filtro de caminho. Por exemplo, um teste do Node.JS será ignorado em um pull request que apenas corrige um erro no seu arquivo README e não faz alterações nos arquivos JavaScript e TypeScript no diretório scripts.

Se esta verificação é necessária e for ignorada, o status da verificação é exibido como pendente, porque é necessário. Nesse caso, você não poderá de fazer o merge do pull request.

Exemplo

Neste exemplo, você tem um fluxo de trabalho necessário para passar.

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

Se alguém enviar um pull request que altere um arquivo de markdown na raiz do repositório, o fluxo de trabalho acima não será executado devido ao filtro de caminho. Como resultado, você não poderá fazer o merge do pull request. Você verá o seguinte status no pull request:

Verificação obrigatória ignorada mas mostrada como pendente

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/**'
      - 'middleware/**'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: 'echo "No build required" '

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

Verificação ignorada mas passa graças a um fluxo de trabalho genérico

Notas:

  • Certifique-se de que a chave nome e o nome do trabalho necessário sejam o mesmo em ambos os arquivos do fluxo de trabalho. Para obter mais informações, consulte "Sintaxe do fluxo de trabalho para 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.