Verificações de status de solicitação de pull disponíveis

Serviços do Azure DevOps

As verificações de status impõem padrões de qualidade bloqueando mesclagens até que os testes sejam aprovados, verificações de segurança desmarcadas ou outras condições sejam atendidas. Azure DevOps Serviços e ferramentas externas postam verificações de status usando a API de Status de PR.

Para exigir uma verificação de status como uma política de branch, crie uma política na seção Status para verificar e especifique o Gênero e o Nome da verificação no formato genre/name. A solicitação de pull bloqueia mesclagens até que a verificação seja reportada succeeded.

Valores de status e comportamento de mesclagem

Quando uma verificação de status publica um resultado em uma solicitação de pull, ela relata um dos seguintes valores:

Valor Comportamento com a política necessária Comportamento com política opcional
succeeded ✓ Desbloqueia a política Informativo
failed ✗ Blocos de mesclagem Informativo
error ✗ Blocos de mesclagem Informativo
pending ⏳ Blocos de mesclagem (aguardando resultado) Informativo
notApplicable ✓ Ignora o requisito de política Informativo
notSet ⏳ Tratado como pendente Informativo

Note

Quando uma política necessária é definida como Aplicar por padrão, você pode postar notApplicable para remover o requisito de política para uma PR específica sem alterar a configuração da política. Isso é útil quando uma verificação não é aplicável a uma alteração específica.

Para obter instruções gerais sobre como adicionar uma política de verificação de status, consulte Configurar uma política de branch para um serviço externo. Para obter opções de política avançadas, incluindo restrições de identidade autorizadas e configurações de aplicabilidade de política, consulte Personalizar e estender fluxos de trabalho de solicitação de pull com o status da solicitação de pull.

Verificações de status de Azure DevOps de primeira parte

Veja a seguir as únicas verificações de status postadas nativamente pelo Azure DevOps Services. Cada verificação usa um valor de Gênero fixo, para que você possa configurar a política de branch antes ou depois que o serviço postar seu primeiro status. Todas as outras verificações de status vêm de serviços externos por meio da API de Status de PR.

GitHub Advanced Security para Azure DevOps

Essas verificações de status exigem GitHub Segurança Avançada para que Azure DevOps sejam habilitados no repositório. As verificações avaliam as vulnerabilidades de segurança detectadas na verificação de código (CodeQL), verificação de dependência e verificação secreta.

Gênero Name Estado para marcar Description
AdvancedSecurity AllHighAndCritical AdvancedSecurity/AllHighAndCritical Bloqueia mesclagens quando houver qualquer vulnerabilidade de gravidade crítica ou alta não resolvida no repositório de qualquer tipo de verificação (código, dependência ou segredo). Requer uma política de validação de build com tarefas de pipeline de Segurança Avançada habilitadas.
AdvancedSecurity NewHighAndCritical AdvancedSecurity/NewHighAndCritical Bloqueia mesclagens quando a solicitação de pull introduz novas vulnerabilidades críticas ou de alta gravidade de qualquer tipo de verificação. As vulnerabilidades existentes do repositório não bloqueiam a mesclagem. Requer uma política de validação de build com tarefas de pipeline de Segurança Avançada para verificar o branch de PR.

Note

Ambas as AdvancedSecurity verificações de status exigem uma política de validação de build e tarefas de verificação de Segurança Avançada configuradas Wait for Processing: true para garantir que os status reflitam os resultados mais recentes da verificação. Para verificação de dependência ou verificação de código (CodeQL), habilite Wait for Processing na AdvancedSecurity-Publish tarefa. Para verificação de código, habilite-a também na AdvancedSecurity-CodeQL-Analyze tarefa. Ambas as verificações aparecem no Status para verificar a lista suspensa após a primeira execução bem-sucedida do pipeline com a verificação de Segurança Avançada.

Dica

Se o repositório tiver alertas não resolvidos existentes, comece AdvancedSecurity/NewHighAndCritical a evitar bloquear todas as solicitações de pull imediatamente. Migre para depois que AdvancedSecurity/AllHighAndCritical a lista de pendências de alerta for resolvida.

Para obter instruções de instalação, consulte Configurar verificações de status da solicitação de pull.

Importante

Deixe as Opções Avançadas em seus padrões ao configurar a política de verificação de status. Alterar a identidade autorizada ou exigir uma ID de iteração impede que as verificações de status sejam postadas corretamente.

cobertura de código Azure Pipelines

Azure Pipelines publica automaticamente uma verificação de status de cobertura de código quando um pipeline publica resultados de cobertura de código para uma solicitação pull. O gênero é o nome do pipeline, portanto, o valor exato genre/name depende de como você nomeou seu pipeline.

Gênero Name Estado para marcar Description
{pipeline-name} codecoverage {pipeline-name}/codecoverage Relata o percentual de cobertura diferida para linhas alteradas na solicitação de pull. Consultoria por padrão; não bloqueia mesclagens, a menos que seja configurada como uma política de branch necessária com um limite mínimo de cobertura.

O limite de aprovação padrão é 70% cobertura diferente. Para ajustar o limite e outras configurações, adicione um azurepipelines-coverage.yml arquivo à raiz do repositório:

coverage:
  status:
    comments: on
    diff:
      target: 80

Substitua 80 pelo percentual mínimo de cobertura de difusão desejado.

Para obter instruções de instalação, consulte Impor proteção de branch com uma política de cobertura de código.

Dica

O gênero é derivado do nome de exibição do pipeline em Azure Pipelines; ele não é um valor configurável separadamente. Por exemplo, um pipeline chamado CI – Main usa CI - Main/codecoverage como o Status para verificar o valor. As verificações de status só aparecem na lista suspensa depois que o serviço tiver postado pelo menos um status em uma solicitação de pull. Para novas integrações que ainda não foram executadas, digite o genre/name valor diretamente no campo.

Verificações de status personalizadas e externas

Qualquer serviço que use a API de Status de PR pode postar uma verificação de status em suas solicitações de pull. Para postar uma verificação de status por meio da API REST, a identidade de chamada precisa da permissão Contribuir para efetuar pull de solicitações no repositório.

Quando um serviço posta um status, ele genre/name aparece no Status para verificar a lista suspensa quando você adiciona uma política. Para novos serviços que ainda não foram postados, digite o genre/name valor diretamente.

Padrões comuns de integração

Tipo de integração Description Examples
Criar e testar servidores Ferramentas de CI externas que postam resultados aprovados ou reprovados após a execução de testes no branch de PR. Jenkins, GitLab CI, CircleCI, Travis CI
Análise de qualidade de código Ferramentas de análise estática que verificam o código em busca de bugs, vulnerabilidades e cheiros de código. SonarQube
Scanners de segurança Scanners de vulnerabilidade não Microsoft que postam resultados após a verificação de alterações de RP. Também dá suporte aos resultados do formato SARIF. Snyk, Checkmarx, WhiteSource (Mend), Segurança da Microsoft DevOps
Conformidade e política Ferramentas de imposição de política que verificam licenciamento, padrões de código, requisitos regulatórios ou preparação para implantação. Verificadores de conformidade personalizados, portões de implantação, scanners de licença
GitHub Actions Verificações de fluxos de trabalho GitHub Actions aparecem em PRs Azure DevOps quando o repositório está conectado a GitHub. Consulte Azure DevOps GitHub integração para obter detalhes de configuração. Qualquer fluxo de trabalho GitHub Actions pode postar status
Aprovações e portões Serviços que exigem aprovação manual ou automatizada antes que mesclagens sejam permitidas. ServiceNow, serviços de aprovação personalizados por meio da API REST

Opções de configuração de política

Ao adicionar uma política de verificação de status, você pode configurar:

  • Requisito de política: defina a política conforme necessário (bloqueia mesclagens, a menos que a verificação passe) ou opcional (somente informativa).
  • Identidade autorizada: restrinja quais contas podem postar valores de status que atendem à política. Deixe em branco para permitir qualquer conta.
  • Condições de redefinição: especifique se o status é redefinido quando uma nova confirmação é enviada por push. Por padrão, enviar por push uma nova confirmação redefine as verificações de status necessárias para pendentes, forçando-as a avaliar seu código mais recente. Para permitir que um status persista entre confirmações, desabilite o status de redefinição sempre que houver novas alterações.
  • Aplicabilidade da política: escolha se a política se aplica imediatamente (aplicar por padrão) ou somente depois que o primeiro status é postado (condicional).
    • Aplicar por padrão: os blocos de política se mesclam até que um succeeded status seja postado. Você pode postar notApplicable para ignorar o requisito de uma PR específica.
    • Condicional: a política só se torna ativa depois que a verificação publica seu primeiro status.
  • Filtro de caminho: restrinja a política a PRs que modificam arquivos em caminhos específicos (opcional).

Para implementar uma verificação de status personalizada, consulte:

Conteúdo relacionado

  • Last updated on