Personalizza ed estendi i flussi di lavoro delle richieste pull utilizzando lo stato delle richieste pull.

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Richieste pull sono uno strumento ideale per facilitare le revisioni del codice e gestire il movimento del codice all'interno di un repository. I criteri di ramo applicano la qualità del codice durante il processo di pull request stabilendo i requisiti che devono essere eseguiti per ogni modifica del codice. Questi criteri consentono ai team di applicare molte procedure consigliate correlate alla revisione del codice e all'esecuzione di compilazioni automatizzate, ma molti team hanno requisiti e convalide aggiuntivi da eseguire sul codice. Per soddisfare queste esigenze individuali e personalizzate, Azure Repos offre gli stati dei pull request. Gli stati delle richieste pull si integrano nel flusso di lavoro della richiesta pull e consentono ai servizi esterni di approvare a livello di codice un cambiamento nel codice associando semplici informazioni di tipo successo/fallimento alla richiesta pull. Facoltativamente, le richieste pull possono essere bloccate fino a quando il servizio esterno non approva la modifica.

Prerequisiti

Categoria	Requisiti
Accesso al progetto	Membro di un progetto.
Autorizzazioni	- Visualizzare il codice nei progetti privati: almeno livello di accesso Basic . - Clonare o contribuire al codice nei progetti privati: membro del gruppo di sicurezza Contributors o con autorizzazioni corrispondenti nel progetto. - Impostare le autorizzazioni per il branch o il repository: Gestire i permessi permessi per il branch o il repository. - Cambiare il ramo predefinito: Modificare le politiche e le autorizzazioni per il repository. - Importare un repository: membro del gruppo di sicurezza amministratori del progetto o autorizzazione a livello di progetto Git Crea repository impostata su Consenti. Per altre informazioni, vedere Impostare le autorizzazioni del repository Git.
Servizi	Repos abilitato.
Strumenti	Opzionale. Usa i comandi az repos: Azure DevOps CLI.

Nota

Nei progetti pubblici, gli utenti con accesso Stakeholder hanno accesso completo ad Azure Repos, compresa la visualizzazione, la clonazione e il contributo al codice.

L'integrazione nel flusso di lavoro delle pull request comprende diversi concetti:

• stato della richiesta pull: consente ai servizi di associare informazioni sull'esito positivo/negativo a una richiesta pull.
• Politica di stato: fornisce un meccanismo per bloccare il completamento della richiesta di pull fino a quando lo stato della richiesta non indica un esito positivo.
• Azioni personalizzate: consente di estendere il menu di stato usando le estensioni di Azure DevOps Services.

In questo argomento imparerai sugli stati dei pull request e su come possano essere usati per integrarsi nel flusso di lavoro del PR.

Stato della richiesta di pull

Lo stato della richiesta pull consente ai servizi di associare informazioni semplici sul tipo di esito positivo/negativo a una richiesta pull, usando l'API stato . Uno stato è costituito da quattro parti chiave di dati:

• Stato. Uno degli stati predefiniti seguenti: succeeded, failed, pending, notSet, notApplicableo error.
• Descrizione. Stringa che descrive lo stato dell'utente finale.
• Contesto. Nome dello stato, che solitamente descrive l'entità che registra lo stato.
• URL. Collegamento in cui gli utenti possono ottenere informazioni più specifiche dello stato.

Essenzialmente, lo stato è il modo in cui un utente o un servizio pubblica la propria valutazione su una richiesta pull e fornisce la risposta a domande come:

• Le modifiche soddisfano i requisiti?
• Dove è possibile ottenere altre informazioni sulle operazioni da eseguire per soddisfare i requisiti?

Esaminiamo un esempio. Si consideri un servizio CI necessario per compilare tutte le modifiche al codice in un progetto. Quando tale servizio valuta le modifiche in una richiesta pull, deve pubblicare i risultati della compilazione e dei test. Per le modifiche che superano la build, è possibile pubblicare uno stato simile al seguente nella pull request:

{
    "state": "succeeded",
    "description": "CI build succeeded",
    "context": {
        "name": "my-ci-system",
        "genre": "continuous-integration"
    },
    "targetUrl": "http://contoso.com/CI/builds/1"
}

Questo stato verrà mostrato all'utente finale nella vista dei dettagli della richiesta pull.

• Il state viene visualizzato all'utente usando un'icona (segno di spunta verde per succeeded, X rossa per failed, un orologio per pendinge un rosso ! per error).
• Il description viene visualizzato accanto all'icona e il context è disponibile in un tooltip.
• Quando viene applicato un targetUrl, la descrizione verrà visualizzata come un collegamento all'URL.

Aggiornamento dello stato

Un servizio può aggiornare lo stato di una richiesta pull per una singola richiesta pull pubblicando stati aggiuntivi, ma solo l'ultimo stato pubblicato viene mostrato per ogni contextunivoco. La pubblicazione di più stati aiuta gli utenti a gestire le aspettative. Ad esempio, l'inserimento di un pending di stato è un buon modo per confermare all'utente che un sistema ha ricevuto un evento e sta iniziando il lavoro. L'uso di un description informativo, ad esempio gli esempi seguenti, può aiutare ulteriormente l'utente a comprendere il funzionamento del sistema:

• "Compilazione in coda"
• Costruzione in corso
• "Compilazione riuscita"

Stato dell'iterazione

Quando il ramo di origine in una pull request cambia, viene creata una nuova "iterazione" per tenere traccia delle modifiche più recenti. I servizi che valutano le modifiche del codice vorranno pubblicare un nuovo stato su ogni iterazione di una pull request. La pubblicazione dello stato su un'iterazione specifica di una richiesta pull garantisce che lo stato si applichi solo al codice valutato e non agli aggiornamenti futuri.

Nota

Se la richiesta pull creata contiene più di 100.000 file modificati, per motivi di prestazioni e stabilità, tale richiesta pull non supporterà le iterazioni. Ciò significa che qualsiasi modifica aggiuntiva a tale pull request verrà inclusa, ma non verrà creata alcuna nuova iterazione per quella modifica. Inoltre, qualsiasi tentativo di creare uno stato per un'iterazione inesistente restituirà un errore.

Viceversa, se lo stato pubblicato si applica all'intera richiesta pull, indipendentemente dal codice, la registrazione all'iterazione potrebbe non essere necessaria. Ad esempio, verificare che l'autore (una proprietà PR non modificabile) appartenga a un gruppo specifico viene valutato una sola volta e lo stato di iterazione non sarebbe necessario.

Quando si configurano i criteri di stato, se viene usato lo stato dell'iterazione, Le condizioni di reimpostazione devono essere impostate su Reimposta stato ogni volta che vengono apportate nuove modifiche. Ciò garantisce inoltre che la richiesta pull non potrà essere unita fino a quando l'ultima iterazione non avrà lo stato di succeeded.

Vedere gli esempi dell'API REST per registrare lo stato in un'iterazione e in una richiesta pull.

Criteri di stato

Utilizzando esclusivamente lo stato, i dettagli di un servizio esterno possono essere forniti agli utenti nell'ambito dell'esperienza PR. In alcuni casi, condividere informazioni su un PR è tutto ciò che è necessario, ma in altri casi i PR devono essere bloccati dalla fusione fino a quando non vengono soddisfatti i requisiti. Analogamente alle politiche predefinite, la politica di stato consente ai servizi esterni di bloccare il completamento delle pull request fino a quando non vengono soddisfatti i requisiti. Se la politica è necessaria, è necessario che venga approvata per completare la richiesta pull. Se il criterio è facoltativo, è solo informativo e lo stato di succeeded non è richiesto per completare il pull request.

I criteri di stato vengono configurati esattamente come gli altri criteri di ramo . Quando si aggiunge un nuovo criterio di stato, è necessario immettere il nome e il genere del criterio di stato. Se lo stato è stato pubblicato in precedenza, è possibile selezionarlo dall'elenco; se si tratta di un nuovo criterio, è possibile digitare il nome del criterio nel formato genere/nome.

Quando si specifica un criterio di stato, è necessario che lo stato di succeeded con il context corrispondente al nome selezionato sia presente per consentire il passaggio di questo criterio.

È anche possibile selezionare un account autorizzato per richiedere che un account specifico disponga dell'autorità per pubblicare lo stato che approverà la politica.

Applicabilità dei criteri

Le opzioni di applicabilità della politica determinano se questa politica viene applicata non appena viene creata una richiesta pull, o se viene applicata solo dopo la pubblicazione del primo stato nella richiesta pull.

applicabilità della politica

1. Applica per impostazione predefinita: il criterio viene applicato non appena viene creata la richiesta pull. Con questa opzione, la politica non viene approvata dopo la creazione della richiesta pull finché non viene pubblicato uno stato di succeeded. Una richiesta pull può essere contrassegnata come esente dalla politica impostando uno stato di notApplicable, che rimuoverà il requisito della politica.

2. Condizionale - La politica non si applica fino a quando il primo stato non viene pubblicato sul pull request.

Insieme, queste opzioni possono essere usate per creare una suite di criteri dinamici. Un criterio di "orchestrazione" di primo livello può essere impostato per essere applicato di default mentre la PR viene valutata per i criteri applicabili. Quindi, quando vengono determinati criteri condizionali aggiuntivi da applicare (ad esempio, in base a uno specifico output di compilazione), è possibile pubblicare lo stato per renderli obbligatori. Questo criterio di orchestrazione potrebbe essere contrassegnato succeeded al termine della valutazione o potrebbe essere contrassegnato notApplicable per indicare alla pull request che il criterio non è applicabile.

Azioni personalizzate

Oltre agli eventi di hook del servizio predefiniti che possono attivare il servizio per aggiornare lo stato del PR, è possibile estendere il menu di stato usando estensioni di Azure DevOps Services per consentire azioni di attivazione all'utente finale. Ad esempio, se lo stato corrisponde a un'esecuzione di test che può essere riavviata dall'utente finale, è possibile disporre di un riavvia voce di menu al menu di stato che attiverebbe l'esecuzione dei test. Per aggiungere un menu di stato, è necessario usare il modello di contributo . Per altre informazioni, vedere l'esempio di estensione Azure DevOps.

Passaggi successivi

Scopri di più sull'API stato di PR e consulta le guide pratiche:

• Creare un server di stato della richiesta pull con Node.js
• Usare Funzioni di Azure per creare criteri ramo personalizzati
• Configurare un criterio di filiale per un servizio esterno