Utlös en pipeline efter en annan

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

• YAML-pipelines
• klassiska rörledningar

Stora produkter har flera komponenter som är beroende av varandra. Dessa komponenter är ofta fristående byggda. När en överordnad komponent (till exempel ett bibliotek) ändras måste underordnade beroenden återskapas och återkallas.

I sådana situationer lägger du till en pipelineutlösare för att köra pipelinen när pipeline lyckas avsluta och trigga pipeline.

Not

Tidigare har du kanske navigerat till den klassiska redigeraren för YAML-pipelinen och konfigurerat byggutlösare i användargränssnittet. Även om modellen fortfarande fungerar rekommenderas den inte längre. Den rekommenderade metoden är att ange pipeline-utlösare direkt i YAML-filen. Utlösare för kompileringsslut som definierats i den klassiska redigeraren har olika nackdelar, som nu har åtgärdats i pipelinesutlösare. Det finns till exempel inget sätt att utlösa en pipeline på samma gren som den utlösande pipelinen med hjälp av utlösare för bygge.

Utlösare som definieras med hjälp av användargränssnittet för pipelineinställningar har företräde framför YAML-utlösare. För att ta bort schemalagda utlösare i användargränssnittet från en YAML-pipeline, se UI-inställningar åsidosätter schemalagda YAML-utlösare.

Konfigurera pipeline-resurs-utlösare

Om du vill utlösa en pipeline när en annan pipeline har slutförts konfigurerar du en pipelineresurs utlösare.

I följande exempel konfigureras en pipelineresursutlösare så att en pipeline med namnet app-ci körs när en körning av security-lib-ci pipeline har slutförts.

I det här exemplet finns följande två pipelines.

• security-lib-ci – Den här pipelinen körs först.

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

• app-ci – Den här pipelinen har en pipelineresursutlösare som konfigurerar app-ci pipeline så att den körs automatiskt varje gång en körning av security-lib-ci pipelinen slutförs.

  # 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 anger namnet på pipelineresursen. Använd etiketten som definieras här när du refererar till pipelineresursen från andra delar av pipelinen, till exempel när du använder pipelineresursvariabler eller laddar ned artefakter.
• source: security-lib-ci anger namnet på pipelinen som refereras av den här pipelineresursen. Du kan hämta en pipelines namn från flera platser i Azure DevOps-portalen, till exempel landningssidan Pipelines. Som standard namnges pipelines efter lagringsplatsen som innehåller pipelinen. Information om hur du uppdaterar en pipelines namn finns i Pipelineinställningar. Om pipelinen finns i en mapp inkluderar du mappnamnet, inklusive den inledande \, till exempel \security pipelines\security-lib-ci.
• project: FabrikamProject – Om den utlösande pipelinen finns i ett annat Azure DevOps-projekt måste du ange projektnamnet. Den här egenskapen är valfri om både källpipelinen och den utlösta pipelinen finns i samma projekt. Om du anger det här värdet och pipelinen inte utlöses läser du anteckningen i slutet av det här avsnittet.
• trigger: true – Använd den här syntaxen för att utlösa pipelinen när någon version av källpipelinen har slutförts. Se följande avsnitt i den här artikeln för att lära dig hur du filtrerar vilka versioner av källpipelinen som, när de är slutförda, utlöser en körning. När filter har angetts måste körningen av källpipelinan matcha alla filter för att starta en körning.

Om den utlösande pipelinen och den utlösta pipelinen använder samma lagringsplats, körs båda pipelines med samma commit när den ena utlöser den andra. Det här är användbart om din första pipeline skapar koden och den andra pipelinen testar den. Men om de två pipelinerna använder olika lagringsplatser använder den utlösta pipelinen versionen av koden i den gren som anges av inställningen Default branch for manual and scheduled builds enligt beskrivningen i Branch considerations for pipeline completion triggers.

Not

I vissa scenarier innehåller standardgrenen för manuella versioner och schemalagda versioner inte ett refs/heads prefix. Standardgrenen kan till exempel vara inställd på main i stället för på refs/heads/main. I det här scenariot fungerar inte en utlösare från ett annat projekt. Om du får problem när du anger project till ett annat värde än målpipelinens kan du uppdatera standardgrenen så att den inkluderar refs/heads genom att ändra dess värde till en annan gren och sedan ändra tillbaka den till den standardgren som du vill använda.

Det går inte att konfigurera utlösare för slutförande av pipeline i YAML-mallar. Du kan fortfarande definiera pipelineresurser i mallar.

Grenfilter

Du kan också ange vilka grenar som ska inkluderas eller exkluderas när du konfigurerar utlösaren. Om du anger grenfilter utlöses en ny pipeline när en källpipelinekörning har slutförts som matchar grenfiltren. I följande exempel körs app-ci-pipelinen om security-lib-ci slutförs på någon releases/*-gren, förutom releases/old*.

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

Om du vill utlösa den underordnade pipelinen för olika grenar som det överordnade objektet utlöses för, tar du med alla grenfilter som det överordnade objektet utlöses för. I följande exempel körs pipelinen app-ci när security-lib-ci slutförs på någon releases/* gren eller huvudgren, utom för releases/old*.

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

Notera

Om grenfiltren inte fungerar kan du prova att använda prefixet refs/heads/. Använd till exempel refs/heads/releases/old*i stället för releases/old*.

Filter för taggar

Note

Stöd för taggfilter för pipelineresurser kräver Azure DevOps Server 2020 Update 1 eller senare.

Egenskapen tags för trigger filtrerar vilka pipelinesluthändelser som kan utlösa din pipeline. Om den utlösande pipelinen matchar alla taggar i listan tags körs pipelinen.

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

Not

Pipelineresursen har dessutom en egenskap som heter tags. tags-egenskapen för pipelineresursen används för att avgöra från vilken pipelinekörning artefakter ska hämtas, när pipelinen utlöses manuellt eller av en schemalagd utlösare. Mer information finns i Resurser: pipelines och Utvärdering av artefaktversion.

Stegfilter

Notera

Etappfilter för resursutlösare i pipeline kräver Azure DevOps Server 2020 Update 1 eller senare.

Du kan utlösa din pipeline när en eller flera steg i den utlösande pipelinen slutförs med hjälp av filtret stages. Om du anger flera steg körs den utlösta pipelinen när alla de angivna stegen har slutförts.

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. 

Branchöverväganden

Pipeline-slutförandeutlösare använder standardgrenen för manuella och schemalagda versioner inställning för att avgöra vilken grens version av en YAML-pipelines grenfilter som ska utvärderas när du avgör om en pipeline ska köras till följd av att en annan pipeline slutförs. Som standard pekar den här inställningen på standardgrenen för lagringsplatsen.

När en pipeline är klar utvärderar Azure DevOps-miljön grenfiltren för resursutlösare i alla pipelines med pipelineavslutningsutlösare som refererar till den slutförda pipelinen. En pipeline kan ha flera versioner i olika grenar, så körtiden utvärderar grenfiltren i pipelineversionen i den gren som specificerats av inställningen Default branch for manual and scheduled builds. Om det finns en matchning körs pipelinen, men den version av pipelinen som körs kan finnas i en annan gren beroende på om den utlösta pipelinen finns på samma lagringsplats som den slutförda pipelinen.

• Om de två pipelinerna finns i olika lagringsplatser körs den utlösta pipelineversionen i grenen som anges av Default branch for manual and scheduled builds.
• Om de två pipelinerna finns i samma lagringsplats körs den utlösta pipelineversionen i samma gren som den utlösande pipelinen (med pipelineversionen från den grenen när utlösarvillkoret uppfylls), även om den grenen skiljer sig från Default branch for manual and scheduled builds, eller om den versionen inte har grenfilter som matchar den slutförda pipelinens gren. Det beror på att grenfiltren från Default branch for manual and scheduled builds-grenen används för att avgöra om pipelinen ska köras och inte förgreningsfiltren i den version som finns i den slutförda pipelinegrenen.

Om utlösare för slutförande av pipeline inte verkar aktiveras, kontrollera värdet för inställningen Standardgren för manuella och schemalagda versioner i den aktuella pipelinen. Grenfiltren i den specifika grenens version av pipelinen används för att avgöra om avslutningsutlösaren för pipelinen initierar en körning. Som standard är Default branch for manual and scheduled builds inställd på standardgrenen för lagringsplatsen, men du kan ändra den när pipelinen har skapats.

Ett typiskt scenario där utlösaren för pipelinens slutförande inte utlöses är när en ny gren skapas, och utlösargrensfiltren för pipelinens slutförande ändras så att den inkluderar den nya grenen, men när den första pipelinen slutförs på en gren som matchar de nya grenfiltren utlöses inte den andra pipelinen. Detta inträffar om grenfiltren i pipelineversionen i Default branch for manual and scheduled builds-grenen inte matchar den nya grenen. För att lösa det här utlösarproblemet har du följande två alternativ.

• Uppdatera grenfiltren i pipelinen i Default branch for manual and scheduled builds-grenen så att de matchar den nya grenen.
• Uppdatera standardgrenen för manuella och schemalagda kompileringar inställning till en gren som har en version av pipelinen med de grenfilter som matchar den nya grenen.

Kombinera utlösartyper

När du anger både CI-utlösare och pipelineutlösare i din pipeline kan du förvänta dig att nya körningar startas varje gång en push görs som matchar ci-utlösarens filter, och en körning av källpipelinen slutförs som matchar filtren för pipelinens slutförandeutlösare.

Tänk dig till exempel två pipelines med namnet A och B som finns på samma lagringsplats, båda har CI-utlösare och B har en pipeline-slutförandeutlösare konfigurerad för slutförande av pipelinen A. Om du gör en push-överföring till lagringsplatsen:

• En ny körning av A startas baserat på dess CI-utlösare.
• Samtidigt startas en ny körning av B, baserat på dess CI-utlösare. Den här körningen använder pipelinen A:s artefakter från en tidigare körning.
• När A har slutförts utlöser det en ny körning av B, baserat på pipeline-slutförandeutlösaren i B.

För att förhindra att två körningar av B utlöses i det här exemplet måste du inaktivera dess CI-utlösare (trigger: none) eller pipeline-utlösare (pr: none).