Condividi tramite

Attivare una pipeline dopo un'altra

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

I prodotti di grandi dimensioni hanno diversi componenti che dipendono l'uno dall'altro. Questi componenti vengono spesso compilati in modo indipendente. Quando un componente upstream (ad esempio una libreria) cambia, le dipendenze downstream devono essere ricompilate e riconvalidate.

In situazioni come queste, aggiungere un trigger della pipeline per eseguire la pipeline al completamento corretto della pipeline di attivazione della pipeline.

Nota

In precedenza, è possibile passare all'editor classico per la pipeline YAML e aver configurato trigger di completamento della compilazione nell'interfaccia utente. Anche se il modello funziona ancora, non è più consigliato. L'approccio consigliato consiste nel specificare trigger della pipeline direttamente all'interno del file YAML. I trigger di completamento della compilazione definiti nell'editor classico presentano diversi svantaggi, che ora sono stati risolti nei trigger della pipeline. Ad esempio, non è possibile attivare una pipeline nello stesso ramo della pipeline di attivazione usando trigger di completamento della compilazione.

I trigger definiti usando l'interfaccia utente delle impostazioni della pipeline hanno la precedenza sui trigger YAML. Per eliminare i trigger pianificati dell'interfaccia utente da una pipeline YAML, vedere impostazioni dell'interfaccia utente sostituiscono i trigger pianificati YAML.

Configurare i trigger delle risorse della pipeline

Per attivare una pipeline al completamento di un'altra pipeline, configurare un trigger di risorsa pipeline.

Nell'esempio seguente viene configurato un trigger di risorsa della pipeline in modo che una pipeline denominata app-ci venga eseguita dopo il completamento di qualsiasi esecuzione della pipeline security-lib-ci.

Questo esempio include le due pipeline seguenti.

  • security-lib-ci: questa pipeline viene eseguita per prima.

    # security-lib-ci YAML pipeline
steps:
- bash: echo "The security-lib-ci pipeline runs first"

  • app-ci: questa pipeline include un trigger di risorse della pipeline che configura la pipeline di app-ci per l'esecuzione automatica ogni volta che viene completata un'esecuzione della pipeline di security-lib-ci.

    # app-ci YAML pipeline
# We are setting up a pipeline resource that references the security-lib-ci
# pipeline and setting up a pipeline completion trigger so that our app-ci
# pipeline runs when a run of the security-lib-ci pipeline completes
resources:
  pipelines:
  - pipeline: securitylib # Name of the pipeline resource.
    source: security-lib-ci # The name of the pipeline referenced by this pipeline resource.
    project: FabrikamProject # Required only if the source pipeline is in another project
    trigger: true # Run app-ci pipeline when any run of security-lib-ci completes

steps:
- bash: echo "app-ci runs after security-lib-ci completes"
  • - pipeline: securitylib specifica il nome della risorsa della pipeline. Usare l'etichetta definita qui quando si fa riferimento alla risorsa della pipeline da altre parti della pipeline, ad esempio quando si usano variabili di risorsa della pipeline o si scaricano elementi.
  • source: security-lib-ci specifica il nome della pipeline a cui fa riferimento questa risorsa di pipeline. È possibile recuperare il nome di una pipeline dal portale Azure DevOps in diverse posizioni, come nella pagina di destinazione Pipelines . Per impostazione predefinita, le pipeline sono denominate in base al repository che le contiene. Per aggiornare il nome di una pipeline, vedere le impostazioni della pipeline . Se la pipeline è contenuta in una cartella, includere il nome della cartella, incluso il \iniziale, ad esempio \security pipelines\security-lib-ci.
  • project: FabrikamProject: se la pipeline di attivazione si trova in un altro progetto di Azure DevOps, è necessario specificare il nome del progetto. Questa proprietà è facoltativa se sia la pipeline di origine che la pipeline attivata si trovano nello stesso progetto. Se specifichi questo valore e la pipeline non viene attivata, consulta la nota alla fine di questa sezione.
  • trigger: true: usare questa sintassi per attivare la pipeline al termine di qualsiasi versione della pipeline di origine. Vedere le sezioni seguenti in questo articolo per scoprire come filtrare quali versioni della pipeline di origine, quando completate, attiveranno un'esecuzione. Quando vengono specificati filtri, l'esecuzione della pipeline di origine deve corrispondere a tutti i filtri per attivare un'esecuzione.

Se la pipeline di attivazione e la pipeline attivata usano lo stesso repository, entrambe le pipeline verranno eseguite usando lo stesso commit quando si attiva l'altra. Ciò è utile se la prima pipeline compila il codice e la seconda lo testa. Tuttavia, se le due pipeline usano repository diversi, la pipeline attivata userà la versione del codice nel ramo specificato dall'impostazione Default branch for manual and scheduled builds, come descritto nella sezione Considerazioni sul ramo per i trigger di completamento della pipeline.

Nota

In alcuni scenari, il ramo predefinito per le compilazioni manuali e le compilazioni pianificate non include un prefisso refs/heads. Ad esempio, il ramo predefinito potrebbe essere impostato su main anziché su refs/heads/main. In questo scenario, un trigger da un progetto diverso non funziona. Se si verificano problemi quando si imposta project su un valore diverso da quello della pipeline di destinazione, è possibile aggiornare il ramo predefinito in modo da includere refs/heads modificandone il valore in un ramo diverso e quindi modificandolo di nuovo nel ramo predefinito che si vuole usare.

La configurazione dei trigger di completamento della pipeline non è supportata nei modelli YAML. È comunque possibile definire le risorse della pipeline nei modelli.

Filtri di ramo

Facoltativamente, è possibile specificare i rami da includere o escludere durante la configurazione del trigger. Se si specificano filtri di branch, viene attivata una nuova pipeline ogni volta che un'esecuzione della pipeline di origine viene completata correttamente e corrisponde ai filtri di branch. Nell'esempio seguente la pipeline di app-ci viene eseguita se il security-lib-ci viene completato in qualsiasi ramo releases/*, ad eccezione di releases/old*.

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        exclude:
        - releases/old*

Per attivare la pipeline figlio per rami diversi per cui viene attivato l'elemento padre, includere tutti i filtri di ramo per cui viene attivato l'elemento padre. Nell'esempio seguente, la pipeline app-ci viene eseguita se il security-lib-ci è completato su qualsiasi ramo releases/* o sul ramo principale, ad eccezione di releases/old*.

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        - main
        exclude:
        - releases/old*

Nota

Se i filtri del branch non funzionano, provare a usare il prefisso refs/heads/. Ad esempio, usare refs/heads/releases/old*anziché releases/old*.

Filtri tag

Nota

supporto del filtro tag per le risorse della pipeline richiede di Azure DevOps Server 2020 Update 1 o versione successiva.

La proprietà tags del trigger filtra quali eventi di completamento della pipeline possono attivarla. Se la pipeline di attivazione corrisponde a tutti i tag nell'elenco tags, la pipeline viene eseguita.

resources:
  pipelines:
  - pipeline: MyCIAlias
    source: Farbrikam-CI
    trigger:
      tags:        # This filter is used for triggering the pipeline run
      - Production # Tags are AND'ed
      - Signed

Nota

La risorsa della pipeline ha anche una proprietà tags. La proprietà tags della risorsa della pipeline viene usata per determinare l'esecuzione della pipeline da cui recuperare gli artefatti, quando la pipeline viene attivata manualmente o da un trigger pianificato. Per altre informazioni, vedere risorse : pipeline e valutazione della versione dell'artefatto.

Filtri di fase

È possibile attivare la pipeline completando una o più fasi della pipeline di innesco usando il filtro stages. Se si forniscono più fasi, la pipeline attivata viene eseguita al termine di tutte le fasi elencate.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    source: Farbrikam-CI  
    trigger:    
      stages:         # This stage filter is used when evaluating conditions for 
      - PreProduction # triggering your pipeline. On successful completion of all the stages
      - Production    # provided, your pipeline will be triggered.

Considerazioni sul ramo

I trigger di completamento della pipeline usano il ramo predefinito per le compilazioni manuali e pianificate impostazione per determinare la versione del ramo di una pipeline YAML da valutare quando determinare se eseguire una pipeline come risultato del completamento di un'altra pipeline. Per impostazione predefinita, questa impostazione punta al ramo predefinito del repository.

Al termine di una pipeline, il runtime di Azure DevOps valuta i filtri del ramo del trigger di risorsa della pipeline di qualsiasi pipeline con trigger di completamento della pipeline che fanno riferimento alla pipeline completata. Una pipeline può avere più versioni in rami diversi, quindi il runtime valuta i filtri di ramo nella versione della pipeline nel ramo specificato dall'impostazione Default branch for manual and scheduled builds. Se esiste una corrispondenza, la pipeline viene eseguita, ma la versione della pipeline eseguita può trovarsi in un ramo diverso a seconda che la pipeline attivata si trovi nello stesso repository della pipeline completata.

  • Se le due pipeline si trovano in repository diversi, viene eseguita la versione della pipeline attivata nel ramo specificato da Default branch for manual and scheduled builds.
  • Se le due pipeline si trovano nello stesso repository, la versione della pipeline attivata appartenente allo stesso ramo della pipeline di attivazione viene eseguita (usando la versione della pipeline da quel ramo al momento in cui viene soddisfatta la condizione del trigger), anche se quel ramo è diverso da Default branch for manual and scheduled buildse anche se quella versione non ha filtri di ramo che corrispondono al ramo della pipeline completata. Il motivo è che i filtri di ramo del ramo Default branch for manual and scheduled builds vengono usati per determinare se la pipeline deve essere eseguita e non i filtri di ramo nella versione presente nel ramo della pipeline completato.

Se i trigger di completamento della pipeline non sembrano innescarsi, controllare il valore dell'impostazione del ramo predefinito per le compilazioni manuali e pianificate della pipeline attivata. I filtri del ramo nella versione di quella specifica diramazione della pipeline vengono usati per determinare se il trigger di completamento della pipeline avvia un'esecuzione della pipeline. Per impostazione predefinita, Default branch for manual and scheduled builds è impostato sul ramo predefinito del repository, ma è possibile modificarlo dopo la creazione della pipeline.

Uno scenario tipico in cui il trigger di completamento della pipeline non viene attivato è quando viene creato un nuovo ramo e i filtri di attivazione del completamento della pipeline relativi al ramo vengono modificati per includere questo nuovo ramo, ma quando la prima pipeline viene completata su un ramo che corrisponde ai nuovi filtri, tuttavia, la seconda pipeline non viene attivata. Ciò si verifica se i filtri del branch nella versione della pipeline del ramo Default branch for manual and scheduled builds non corrispondono al nuovo ramo. Per risolvere questo problema di trigger, sono disponibili le due opzioni seguenti.

  • Aggiornare i filtri di ramo nella pipeline nel ramo Default branch for manual and scheduled builds in modo che corrispondano al nuovo ramo.
  • Aggiornare il ramo predefinito per le compilazioni manuali e pianificate impostandolo su un ramo che dispone di una versione della pipeline con filtri di ramo che corrispondono al nuovo ramo.

Combinazione dei tipi di trigger

Quando si specificano sia i trigger di integrazione continua sia i trigger della pipeline nella tua pipeline, puoi prevedere l'avvio di nuove esecuzioni ogni volta che viene eseguito un push che corrisponde ai filtri del trigger di integrazione continua e al completamento di un'esecuzione della pipeline di origine corrispondente ai filtri del trigger di completamento della pipeline.

Si considerino, ad esempio, due pipeline denominate A e B che si trovano nello stesso repository, entrambe hanno trigger CI, e B ha un trigger di completamento configurato per il completamento della pipeline A. Se fai un push nel repository:

  • Viene avviata una nuova esecuzione di A in base al trigger CI.
  • Allo stesso tempo, viene avviata una nuova esecuzione di B, in base al trigger CI. Questa esecuzione utilizza gli artefatti di un'esecuzione precedente della pipeline A.
  • Al termine di A, esso attiva un'altra esecuzione di B, in base al trigger di completamento della pipeline in B.

Per impedire l'attivazione di due esecuzioni di B in questo esempio, è necessario disabilitare il trigger CI (trigger: none) o il trigger della pipeline (pr: none).