Attivare una pipeline dopo l'altra

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

• Pipeline YAML
• Pipeline classiche

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.

Nota

In precedenza, è possibile passare all'editor classico per la pipeline YAML e configurare i trigger di completamento della compilazione nell'interfaccia utente. Anche se il modello funziona ancora, non è più consigliato. L'approccio consigliato consiste nel specificare i 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.

Configurare i trigger delle risorse della pipeline

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

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

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 ha un trigger di risorse della pipeline che configura la pipeline per l'esecuzione app-ci automatica ogni volta che viene completata un'esecuzione della security-lib-ci pipeline.

  # 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 della pipeline. È possibile recuperare il nome di una pipeline dal portale di Azure DevOps in diverse posizioni, ad esempio la pagina di destinazione pipeline. Per impostazione predefinita, le pipeline sono denominate dopo il repository che contiene la pipeline. Per aggiornare il nome di una pipeline, vedere Impostazioni della pipeline. Se la pipeline è contenuta in una cartella, includere il nome della cartella, incluso l'elemento 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 si specifica questo valore e la pipeline non viene attivata, vedere la nota alla fine di questa sezione.
• trigger: true - Usare questa sintassi per attivare la pipeline quando viene completata una qualsiasi versione della pipeline di origine. Vedere le sezioni seguenti in questo articolo per informazioni su come filtrare le versioni della pipeline di origine 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 la verifica. 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 in 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 refs/heads prefisso. 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 rami

Facoltativamente, è possibile specificare i rami da includere o escludere durante la configurazione del trigger. Se si specificano filtri di ramo, viene attivata una nuova pipeline ogni volta che un'esecuzione della pipeline di origine viene completata correttamente che corrisponde ai filtri del ramo. Nell'esempio seguente la app-ci pipeline viene eseguita se l'oggetto security-lib-ci viene completato in qualsiasi releases/* ramo, 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 app-ci pipeline viene eseguita se l'oggetto security-lib-ci viene completato in qualsiasi releases/* ramo o 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 ramo non funzionano, provare a usare il prefisso refs/heads/. Usare, ad esempio, refs/heads/releases/old* invece di releases/old*.

Filtri tag

Nota

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

Proprietà tags dei trigger filtri che gli eventi di completamento della pipeline possono attivare la pipeline. 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 tags proprietà . La tags proprietà 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

Nota

I filtri di fasi per i trigger di risorse della pipeline richiedono Azure DevOps Server 2020 Update 1 o versione successiva.

È possibile attivare la pipeline quando una o più fasi della pipeline di attivazione vengono completate usando il stages filtro. 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 per determinare quale versione del ramo di una pipeline YAML filtra per 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 dei rami 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 trova 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 nello stesso ramo della pipeline di attivazione viene eseguita (usando la versione della pipeline da tale ramo al momento in cui viene soddisfatta la condizione del trigger), anche se tale ramo è diverso da Default branch for manual and scheduled buildse anche se tale versione non dispone di filtri di ramo che corrispondono al ramo della pipeline completata. Il motivo è che i filtri di ramo del Default branch for manual and scheduled builds ramo 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 attivarsi, controllare il valore del ramo predefinito per l'impostazione delle compilazioni manuali e pianificate per la pipeline attivata. I filtri del ramo nella versione 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, i filtri del ramo trigger di completamento della pipeline vengono modificati per includere questo nuovo ramo, ma quando la prima pipeline viene completata in un ramo che corrisponde ai nuovi filtri di ramo, la seconda pipeline non viene attivata. Ciò si verifica se il ramo filtra nella versione della pipeline nel Default branch for manual and scheduled builds ramo non corrisponde al nuovo ramo. Per risolvere questo problema di trigger, sono disponibili le due opzioni seguenti.

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

Combinazione dei tipi di trigger

Quando si specificano trigger CI e trigger di pipeline nella pipeline, è possibile prevedere l'avvio di nuove esecuzioni ogni volta che viene eseguito un push che corrisponde ai filtri del trigger di integrazione continua e viene completata 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 di integrazione continua e B hanno un trigger di completamento della pipeline configurato per il completamento della pipeline A. Se si esegue un push nel repository:

• Viene avviata una nuova esecuzione di A , in base al relativo trigger di integrazione continua.
• Allo stesso tempo, viene avviata una nuova esecuzione di B , in base al trigger di integrazione continua. Questa esecuzione usa gli artefatti di un'esecuzione precedente della pipeline A.
• Al A termine, attiva un'altra esecuzione di , in base al trigger di Bcompletamento 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).