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 "Pontos de extremidade da API REST para verificações".
Observação: para serem necessárias, as verificações de status devem ter sido concluídas com êxito no repositório escolhido nos últimos sete dias.
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.
A verificação necessária precisa ser bem-sucedida em relação ao SHA de confirmação mais recente
Para que uma solicitação pull seja mesclada, todas as verificações necessárias devem passar pela última SHA de confirmação. Isso garante que as alterações mais recentes sejam validadas e atendam aos padrões exigidos antes da fusão. As verificações que foram acionadas usando um SHA de confirmação anterior não serão usadas como parte das verificações necessárias.
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.
Se houver um conflito entre o commit de teste de mesclagem e o commit de cabeçalho, as verificações do commit de teste de mesclagem serão mostradas na caixa de seleção de status da solicitação de pull. Isso é indicado na caixa de status da solicitação de pull por uma linha que começa com Showing checks for the merge commit. Para obter mais informações sobre os commits de mesclagem de teste, confira "Pontos de extremidade da API REST para pull requests".
Manipulação ignorada, mas verificações necessárias
Aviso: se um fluxo de trabalho for ignorado devido à filtragem de demarcador, filtragem de ramificação ou a uma mensagem de confirmação, 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.
Você não deve usar a filtragem de demarcador ou ramificação para ignorar execuções de fluxo de trabalho se o fluxo de trabalho for necessário. Para obter mais informações, confira "Ignorar execuções de fluxo de trabalho" e "Fluxos de trabalho necessários".
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, confira "Usando condições para controlar a execução do trabalho".
Quando um trabalho falha, todos os trabalhos que dependem dele são ignorados e não relatam uma falha. Uma pull request que exige a verificação não pode ser bloqueada. Para usar uma verificação obrigatória em um trabalho que depende de outros trabalhos e usar a expressão condicional always() além de needs, confira "Usando trabalhos em um fluxo de 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@v4
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
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ê não deve usar a filtragem de demarcador ou ramificação para ignorar execuções de fluxo de trabalho se o fluxo de trabalho for necessário. Para obter mais informações, confira "Ignorar execuções de fluxo de trabalho" e "Fluxos de trabalho necessários".
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.