Verificações de estado dos pull requests disponíveis

Serviços de DevOps do Azure

As verificações de estado aplicam padrões de qualidade bloqueando fusões até que os testes passem, as análises de segurança sejam resolvidas ou outras condições sejam cumpridas. Os Serviços Azure DevOps e ferramentas externas publicam verificações de estado usando a API PR Status.

Para exigir uma verificação de estado como política de ramo, crie uma política na secção de Estado para verificar e especifique o Género e o Nome do verificador no formato genre/name. O pull request bloqueia então fusões até que a verificação reporte succeeded.

Valores de estado e comportamento de fusão

Quando uma verificação de estado publica um resultado num pull request, reporta um dos seguintes valores:

Value Comportamento com a política necessária Comportamento com política opcional
succeeded ✓ Desbloqueia a apólice Informativo
failed ✗ Blocos fundem-se Informativo
error ✗ Blocos fundem-se Informativo
pending ⏳ Fusão de blocos (aguardando resultado) Informativo
notApplicable ✓ Contorna o requisito da política Informativo
notSet ⏳ Tratado como pendente Informativo

Note

Quando uma política obrigatória está definida como Aplicar por defeito, pode publicar notApplicable para remover o requisito de política para uma RP específica sem alterar a configuração da política. Isto é útil quando um cheque não é aplicável a uma alteração específica.

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

First-party Azure DevOps status checks

A seguir-se as únicas verificações de estado publicadas nativamente pelo Azure DevOps Services. Cada verificação usa um valor fixo de Género , por isso pode configurar a política de branch antes ou depois do serviço publicar o seu primeiro estado. Todas as outras verificações de estado vêm de serviços externos através da API PR Status.

GitHub Advanced Security para o Azure DevOps

Estas verificações de estado exigem que o GitHub Advanced Security for Azure DevOps esteja ativado no repositório. As verificações avaliam vulnerabilidades de segurança detetadas através da varredura de código (CodeQL), varredura de dependências e análise secreta.

Gênero Name Estado a verificar Description
AdvancedSecurity AllHighAndCritical AdvancedSecurity/AllHighAndCritical Bloqueia fusões quando existe qualquer vulnerabilidade crítica ou de alta gravidade não resolvida no repositório de qualquer tipo de varredura (código, dependência ou segredo). Requer uma política de validação de compilações com tarefas do pipeline Advanced Security ativadas.
AdvancedSecurity NewHighAndCritical AdvancedSecurity/NewHighAndCritical Blocos fusão quando o pull request introduz novas vulnerabilidades críticas ou de alta gravidade de qualquer tipo de varrimento. Vulnerabilidades existentes no repositório não bloqueiam a fusão. Requer uma política de validação de build com tarefas de pipeline de Segurança Avançada para analisar o ramo PR.

Note

Ambas AdvancedSecurity as verificações de estado requerem uma política de validação de compilação e tarefas de varredura de Segurança Avançada configuradas para Wait for Processing: true garantir que os estados refletem os resultados mais recentes da varredura. Para varredura de dependências ou de código (CodeQL), ative Wait for Processing a AdvancedSecurity-Publish tarefa. Para digitalização de código, também ative-o na AdvancedSecurity-CodeQL-Analyze tarefa. Ambas as verificações aparecem no menu suspenso de Estado para verificação após a primeira execução bem-sucedida do pipeline com a varredura Advanced Security.

Tip

Se o seu repositório já tiver alertas não resolvidos, comece por AdvancedSecurity/NewHighAndCritical evitar bloquear imediatamente todos os pull requests. Migre para AdvancedSecurity/AllHighAndCritical quando o atraso de alertas estiver resolvido.

Para instruções de configuração, consulte verificações de estado de configurar pull requests.

Importante

Deixe as Opções Avançadas nos seus valores predefinidos ao configurar a política de verificação de estado. Alterar a identidade autorizada ou exigir um ID de iteração impede que as verificações de estado sejam publicadas corretamente.

Azure Pipelines code coverage

O Azure Pipelines publica automaticamente uma verificação do estado da cobertura de código quando um pipeline publica resultados de cobertura de código para um pull request. O género é o nome do pipeline, por isso o valor exato genre/name depende de como nomeaste o pipeline.

Gênero Name Estado a verificar Description
{pipeline-name} codecoverage {pipeline-name}/codecoverage Reporta a percentagem de cobertura do diferencial para linhas alteradas no pull request. Consultoria por defeito; não bloqueia fusões, a menos que esteja configurada como uma política de ramo obrigatória com um limiar mínimo de cobertura.

O limiar padrão de aprovação é 70% cobertura diferencial. Para ajustar o limiar e outras definições, adicione um azurepipelines-coverage.yml ficheiro à raiz do seu repositório:

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

Substitua 80 pela percentagem mínima desejada de cobertura diferencial.

Para instruções de configuração, consulte Enforcer proteção de ramos com uma política de cobertura de código.

Tip

O género deriva do nome de exibição do seu pipeline no Azure Pipelines; não é um valor configurável separadamente. Por exemplo, um pipeline chamado CI - Main é usado CI - Main/codecoverage como Estado para verificar o valor. As verificações de estado só aparecem no menu suspenso depois de o serviço ter publicado pelo menos um estado num pull request. Para novas integrações que ainda não foram executadas, escreva o genre/name valor diretamente no campo.

Verificações de estado personalizadas e externas

Qualquer serviço que utilize a PR Status API pode enviar uma verificação de estado para os seus pull requests. Para publicar uma verificação de estado através da API REST, a identidade que chama precisa da permissão Contribuir para pull requests no repositório.

Quando um serviço publica um estado, aparece genre/name no Estado para verificar o menu suspenso ao adicionar uma política. Para serviços novos que ainda não foram publicados, escreva o genre/name valor diretamente.

Padrões comuns de integração

Tipo de integração Description Examples
Servidores de construção e teste Ferramentas externas de CI que publicam resultados de aprovação ou reprovação após a execução de testes contra o ramo PR. Jenkins, GitLab CI, CircleCI, Travis CI
Análise de qualidade de código Ferramentas de análise estática que analisam código à procura de bugs, vulnerabilidades e cheiros de código. SonarQube, SonarCloud
Scanners de segurança Scanners de vulnerabilidades não-Microsoft que publicam resultados após analisar alterações de PR. Também suporta resultados em formato SARIF. Snyk, Checkmarx, WhiteSource (Mend), Microsoft Security DevOps
Conformidade e política Ferramentas de aplicação de políticas que verificam licenciamentos, normas de código, requisitos regulamentares ou prontidão para a implementação. Verificadores personalizados de conformidade, portas de implementação, scanners de licença
GitHub Actions Verificações dos fluxos de trabalho do GitHub Actions aparecem nos PRs do Azure DevOps quando o repositório está ligado ao GitHub. Consulte Azure DevOps GitHub integração para detalhes de configuração. Qualquer fluxo de trabalho do GitHub Actions pode publicar o estado
Aprovações e limites Serviços que requerem aprovação manual ou automática antes das fusões são permitidos. ServiceNow, serviços personalizados de aprovação via API REST

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

Ao adicionar uma política de verificação de estado, pode configurar:

  • Requisito da política: Definir a política conforme necessário (bloqueia fusões a menos que a verificação seja aprovada) ou opcional (apenas informativo).
  • Identidade autorizada: Restringa que contas podem publicar valores de estado que satisfaçam a política. Deixe em branco para permitir qualquer conta.
  • Condições de reset: Especifique se o estado se reinicia quando um novo commit é empurrado. Por defeito, enviar um novo commit reinicia as verificações de estado para pendentes, obrigando-os a avaliar o seu código mais recente. Para permitir que um estado persista entre os commits, desative o estado de Reset sempre que houver novas alterações.
  • Aplicabilidade da política: Escolha se a política se aplica imediatamente (Aplicar por defeito) ou apenas após o primeiro estado ser publicado (Condicional).
    • Aplicar por defeito: A política bloqueia fusões até que um succeeded estado seja publicado. Podes publicar notApplicable para contornar o requisito de um PR específico.
    • Condicional: A apólice só se torna ativa depois de o cheque publicar o seu primeiro estado.
  • Filtro de caminhos: Restringa a política a PRs que modificam ficheiros em caminhos específicos (opcional).

Para implementar uma verificação de estado personalizada, veja:

Conteúdo relacionado

  • Last updated on