Controlli di stato delle richieste pull disponibili

Servizi di Azure DevOps

I controlli di stato applicano gli standard di qualità bloccando le operazioni di merge fino a quando i test non superano, le analisi di sicurezza cancellano o vengono soddisfatte altre condizioni. Azure DevOps Servizi e strumenti esterni registrano i controlli di stato usando l'API Stato richiesta pull.

Per richiedere un controllo dello stato come criterio di ramo, creare un criterio nella sezione Stato per controllare e specificare il genere e il nome del controllo nel formato genre/name. La richiesta pull blocca quindi l'unione fino a quando il controllo non segnala succeeded.

Valori di stato e comportamento di unione

Quando un controllo dello stato invia un risultato a una richiesta pull, segnala uno dei valori seguenti:

Value Comportamento con i criteri obbligatori Comportamento con criteri facoltativi
succeeded ✓ Sblocca il criterio Di carattere informativo
failed ✗ Blocca unione Di carattere informativo
error ✗ Blocca unione Di carattere informativo
pending ⏳ Blocca unione (risultato in attesa) Di carattere informativo
notApplicable ✓ Ignora i requisiti dei criteri Di carattere informativo
notSet ⏳ Considerato in sospeso Di carattere informativo

Annotazioni

Quando un criterio obbligatorio è impostato su Applica per impostazione predefinita, è possibile pubblicare notApplicable per rimuovere il requisito dei criteri per una richiesta pull specifica senza modificare la configurazione dei criteri. Ciò è utile quando un controllo non è applicabile a una modifica specifica.

Per istruzioni generali sull'aggiunta di un criterio di controllo dello stato, vedere Configurare un criterio di ramo per un servizio esterno. Per le opzioni avanzate dei criteri, incluse le restrizioni di identità autorizzate e le impostazioni di applicabilità dei criteri, vedere Personalizzare ed estendere i flussi di lavoro delle richieste pull con stato della richiesta pull.

Controlli di stato di Azure DevOps di prima parte

Di seguito sono riportati gli unici controlli di stato pubblicati in modo nativo da Azure DevOps Services. Ogni controllo usa un valore Di genere fisso, in modo da poter configurare i criteri di ramo prima o dopo che il servizio ne pubblica il primo stato. Tutti gli altri controlli di stato provengono da servizi esterni tramite l'API Stato richiesta pull.

Sicurezza avanzata di GitHub per Azure DevOps

Questi controlli di stato richiedono GitHub sicurezza avanzata per abilitare Azure DevOps nel repository. I controlli valutano le vulnerabilità di sicurezza rilevate durante l'analisi del codice (CodeQL), l'analisi delle dipendenze e l'analisi dei segreti.

Genere Name Stato da controllare Description
AdvancedSecurity AllHighAndCritical AdvancedSecurity/AllHighAndCritical Blocca le operazioni di merge quando esiste una vulnerabilità critica o elevata non risolta o con gravità elevata nel repository da qualsiasi tipo di analisi (codice, dipendenza o segreto). Richiede un criterio di convalida della compilazione con le attività della pipeline sicurezza avanzata abilitate.
AdvancedSecurity NewHighAndCritical AdvancedSecurity/NewHighAndCritical Blocca l'unione quando la richiesta pull introduce nuove vulnerabilità critiche o con gravità elevata da qualsiasi tipo di analisi. Le vulnerabilità del repository esistenti non bloccano l'unione. Richiede un criterio di convalida della compilazione con attività della pipeline di sicurezza avanzata per analizzare il ramo pr.

Annotazioni

Entrambi AdvancedSecurity i controlli di stato richiedono criteri di convalida della compilazione e attività di analisi avanzata della sicurezza configurate con Wait for Processing: true per garantire che gli stati riflettano i risultati dell'analisi più recenti. Per l'analisi delle dipendenze o l'analisi del codice (CodeQL), abilitare Wait for Processing l'attività AdvancedSecurity-Publish . Per l'analisi del codice, abilitarlo anche nell'attività AdvancedSecurity-CodeQL-Analyze . Entrambi i controlli vengono visualizzati nell'elenco a discesa Stato per controllare dopo la prima esecuzione della pipeline con l'analisi avanzata della sicurezza.

Tip

Se nel repository sono presenti avvisi non risolti, iniziare con AdvancedSecurity/NewHighAndCritical per evitare di bloccare immediatamente tutte le richieste pull. Eseguire la migrazione a AdvancedSecurity/AllHighAndCritical una volta risolto il backlog di avviso.

Per istruzioni sull'installazione, vedere Configurare i controlli di stato della richiesta pull.

Important

Lasciare Le opzioni avanzate per le impostazioni predefinite durante la configurazione del criterio di controllo dello stato. La modifica dell'identità autorizzata o la richiesta di un ID di iterazione impedisce la registrazione corretta dei controlli di stato.

Azure Pipelines code coverage

Azure Pipelines pubblica automaticamente un controllo dello stato di code coverage quando una pipeline pubblica i risultati del code coverage per una richiesta pull. Il genere è il nome della pipeline, quindi il valore esatto genre/name dipende dalla modalità di denominazione della pipeline.

Genere Name Stato da controllare Description
{pipeline-name} codecoverage {pipeline-name}/codecoverage Segnala la percentuale di copertura delle differenze per le righe modificate nella richiesta pull. Avviso per impostazione predefinita; non blocca le unioni a meno che non siano configurate come criteri di ramo obbligatori con una soglia di copertura minima.

La soglia di passaggio predefinita è 70% copertura delle differenze. Per modificare la soglia e altre impostazioni, aggiungere un azurepipelines-coverage.yml file alla radice del repository:

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

Sostituire 80 con la percentuale di copertura minima diff desiderata.

Per istruzioni sull'installazione, vedere Applicare la protezione dei rami con un criterio di code coverage.

Tip

Il genere è derivato dal nome visualizzato della pipeline in Azure Pipelines; non è un valore configurabile separatamente. Ad esempio, una pipeline denominata CI - Main usa CI - Main/codecoverage come stato per controllare il valore. I controlli di stato vengono visualizzati solo nell'elenco a discesa dopo che il servizio ha pubblicato almeno uno stato a una richiesta pull. Per le nuove integrazioni che non sono ancora state eseguite, digitare il genre/name valore direttamente nel campo.

Controlli di stato personalizzati ed esterni

Qualsiasi servizio che usa l'API Stato richiesta pull può inviare un controllo dello stato alle richieste pull. Per pubblicare un controllo dello stato tramite l'API REST, l'identità chiamante richiede l'autorizzazione Contribuire alle richieste pull nel repository.

Quando un servizio pubblica uno stato, il relativo genre/name viene visualizzato nell'elenco a discesa Stato per controllare quando si aggiunge un criterio. Per i nuovi servizi che non sono ancora stati pubblicati, digitare direttamente il genre/name valore.

Modelli di integrazione comuni

Tipo di integrazione Description Examples
Compilare e testare i server Strumenti CI esterni che pubblicano o non superano i risultati dopo l'esecuzione di test sul ramo pr. Jenkins, GitLab CI, CircleCI, Travis CI
Analisi della qualità del codice Strumenti di analisi statici che analizzano il codice per individuare bug, vulnerabilità e odori di codice. SonarQube, SonarCloud
Scanner di sicurezza Scanner di vulnerabilità non Microsoft che pubblicano i risultati dopo l'analisi delle modifiche della richiesta pull. Supporta anche i risultati del formato SARIF. Snyk, Checkmarx, WhiteSource (Mend), Microsoft Security DevOps
Conformità e criteri Strumenti di imposizione dei criteri che verificano licenze, standard di codice, requisiti normativi o conformità alla distribuzione. Controlli di conformità personalizzati, controlli di distribuzione, scanner di licenze
GitHub Actions I controlli dei flussi di lavoro GitHub Actions vengono visualizzati nelle richieste pull Azure DevOps quando il repository è connesso a GitHub. Per informazioni dettagliate sulla configurazione, vedere integrazione di Azure DevOps GitHub. Qualsiasi flusso di lavoro GitHub Actions può registrare lo stato
Approvazioni e controlli Servizi che richiedono l'approvazione manuale o automatizzata prima che siano consentiti i merge. ServiceNow, servizi di approvazione personalizzati tramite l'API REST

Opzioni di configurazione dei criteri

Quando si aggiunge un criterio di controllo dello stato, è possibile configurare:

  • Requisito dei criteri: impostare il criterio come richiesto (blocca le operazioni di unione a meno che non venga superato il controllo) o facoltativo (solo informativo).
  • Identità autorizzata: limitare gli account che possono registrare i valori di stato che soddisfano i criteri. Lasciare vuoto per consentire qualsiasi account.
  • Condizioni di reimpostazione: specificare se lo stato viene reimpostato quando viene eseguito il push di un nuovo commit. Per impostazione predefinita, il push di un nuovo commit reimposta i controlli di stato necessari in sospeso, forzandoli a valutare il codice più recente. Per consentire la persistenza di uno stato tra i commit, disabilitare Lo stato di reimpostazione ogni volta che sono presenti nuove modifiche.
  • Applicabilità dei criteri: scegliere se il criterio viene applicato immediatamente (Applica per impostazione predefinita) o solo dopo la pubblicazione del primo stato (condizionale).
    • Applica per impostazione predefinita: i criteri bloccano l'unione fino a quando non viene pubblicato uno succeeded stato. È possibile inviare un post notApplicable per ignorare il requisito per una richiesta pull specifica.
    • Condizionale: il criterio diventa attivo solo dopo il primo stato del controllo.
  • Filtro percorso: limitare i criteri alle richieste pull che modificano i file in percorsi specifici (facoltativo).

Per implementare un controllo dello stato personalizzato, vedere:

Contenuti correlati

  • Last updated on