Aktivace jednoho kanálu za druhým

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

• kanály YAML
• Klasické pipelines

Velké produkty mají několik komponent, které jsou vzájemně závislé. Tyto komponenty jsou často nezávisle sestaveny. Když se například změní nadřazená komponenta (knihovna), musí se podřízené závislosti znovu vytvořit a znovu aktualizovat.

V takových situacích přidejte spouštěč potrubí, který se spustí po úspěšném dokončení spouštěcího potrubí .

Poznámka

Dříve jste možná přešli do klasického editoru kanálu YAML a nakonfigurovali jste triggery dokončení sestavení v uživatelském rozhraní. I když tento model stále funguje, už se nedoporučuje. Doporučeným přístupem je zadat triggery kanálu přímo v souboru YAML. Triggery pro dokončení sestavení definované v klasickém editoru mají různé nevýhody, které jsou teď vyřešeny v triggerech pipeline. Například neexistuje způsob, jak aktivovat potrubí ve stejné větvi jako to aktivační pomocí triggerů dokončení sestavení.

Triggery definované pomocí uživatelského rozhraní nastavení kanálu mají přednost před triggery YAML. Pokud chcete odstranit naplánované triggery uživatelského rozhraní z potrubí YAML, přečtěte si nastavení uživatelského rozhraní přepisují naplánované triggery YAML.

Konfigurace spouštěčů prostředků pipeline

Pokud chcete kanál aktivovat po dokončení jiného kanálu, nakonfigurujte prostředek kanálu trigger.

Následující příklad nakonfiguruje trigger prostředku pipeline tak, aby se pipeline s názvem app-ci spustila po dokončení jakéhokoli spuštění pipeline security-lib-ci.

Tento příklad obsahuje následující dva kanály.

• security-lib-ci – Tento proces se spustí jako první.

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

• app-ci – Tento kanál má spouštěcí událost zdrojů kanálu, která konfiguruje kanál app-ci tak, aby se spouštěl automaticky pokaždé, když se dokončí běh kanálu 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 určuje název prostředku pipeline. Označení definované zde použijte při odkazování na prostředek pipeline z jiných částí, například při použití proměnných prostředků pipeline nebo při stahování artefaktů.
• source: security-lib-ci určuje název pipeline, na který odkazuje tento prostředek pipeline. Název pipeline můžete načíst z portálu Azure DevOps na několika místech, například na úvodní stránce Pipelines. Ve výchozím nastavení jsou pipeline pojmenovány podle úložiště, které obsahují. Informace o aktualizaci názvu kanálu najdete v tématu Nastavení kanálu. Pokud je kanál obsažen ve složce, zadejte název složky, včetně úvodního \, například \security pipelines\security-lib-ci.
• project: FabrikamProject – Pokud je aktivační kanál v jiném projektu Azure DevOps, musíte zadat název projektu. Tato vlastnost je volitelná, pokud zdrojový kanál i aktivovaný kanál jsou ve stejném projektu. Pokud tuto hodnotu zadáte a potrubí se neaktivuje, podívejte se na poznámku na konci této části.
• trigger: true – Tuto syntaxi použijte k aktivaci pipeline, když se dokončí jakákoli verze zdrojové pipeliny. Podívejte se na následující části tohoto článku, abyste se dozvěděli, jak filtrovat, které verze zdrojového potrubí při dokončení spustí běh. Pokud jsou zadány filtry, musí spuštění zdrojového potrubí odpovídat všem filtrům, aby se spustilo.

Pokud aktivační kanál a aktivovaný kanál používají stejné úložiště, spustí se oba kanály se stejným potvrzením, když jeden aktivuje druhé. To je užitečné, pokud váš první kanál sestaví kód a druhý kanál ho otestuje. Pokud však tyto dva kanály používají různá úložiště, aktivovaný kanál použije verzi kódu ve větvi určeném nastavením Default branch for manual and scheduled builds, jak je popsáno v aspektech větve pro triggery dokončení kanálu.

Poznámka

V některých scénářích výchozí větev ručních sestavení a plánovaných sestavení neobsahuje předponu refs/heads. Výchozí větev může být například nastavená na main místo na refs/heads/main. V tomto scénáři spouštěč z jiného projektu nefunguje. Pokud při nastavování project na jinou hodnotu než cílového kanálu narazíte na problémy, můžete výchozí větev aktualizovat tak, aby zahrnovala refs/heads změnou jeho hodnoty na jinou větev a následnou změnou na výchozí větev, kterou chcete použít.

V šablonách YAML se nepodporují konfigurace triggerů dokončení kanálu. Prostředky pipeline můžete stále definovat v šablonách.

Filtry větví

Volitelně můžete určit větve, které se mají zahrnout nebo vyloučit při konfiguraci triggeru. Pokud zadáte filtry větví, aktivuje se nový kanál vždy, když se úspěšně dokončí spuštění zdrojového kanálu, které odpovídá filtrům větví. V následujícím příkladu se kanál app-ci spustí, pokud se security-lib-ci dokončí v libovolné releases/* větvi s výjimkou releases/old*.

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

Pokud chcete aktivovat podřízený kanál pro různé větve, pro které se aktivuje nadřazený objekt, zahrňte všechny filtry větví, pro které se nadřazený kanál aktivuje. V následujícím příkladu se pipeline app-ci spustí, pokud se security-lib-ci dokončí na libovolné větvi releases/* nebo na hlavní větvi, s výjimkou releases/old*.

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

Poznámka

Pokud filtry větví nefungují, zkuste použít předponu refs/heads/. Například místo releases/old*použijte refs/heads/releases/old*.

Filtry značek

Poznámka

podpora filtru značek pro prostředky kanálu vyžaduje Azure DevOps Server 2020 Update 1 nebo novější.

Vlastnost tags určuje, které dokončovací události potrubí mohou spustit váš pipeline pomocí filtrů trigger. Pokud aktivační potrubí odpovídá všem značkám v seznamu tags, potrubí se spustí.

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

Poznámka

Prostředek kanálu má také vlastnost tags. Vlastnost tags prostředku kanálu slouží k určení, ze kterého kanálu se mají načítat artefakty, když se kanál aktivuje ručně nebo podle naplánovaného triggeru. Více informací viz též Zdroje: potrubí a Hodnocení verze artifactu.

Filtry fází

Poznámka

Filtry fází pro triggery prostředků kanálu vyžadují Azure DevOps Server ve verzi 2020 Update 1 nebo vyšší.

Můžete aktivovat své potrubí, když se dokončí jedna nebo více fází spouštěcího potrubí s použitím filtru stages. Pokud zadáte více fází, spustí se aktivovaný kanál po dokončení všech uvedených fází.

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. 

Zvážení ohledně větví

Spouště dokončení kanálu využívají nastavení Výchozí větev pro ruční a plánované sestavení k určení, kterou verzi větvových filtrů kanálu YAML vyhodnotit při rozhodování, zda se má kanál spustit v důsledku dokončení jiného kanálu. Ve výchozím nastavení odkazuje toto nastavení na výchozí větev úložiště.

Po dokončení kanálu modul runtime Azure DevOps vyhodnotí filtry větve triggeru prostředku kanálu u všech kanálů pomocí triggerů dokončení kanálu, které odkazují na dokončený kanál. Kanál může mít v různých větvích více verzí, takže modul runtime vyhodnotí filtry větví ve verzi kanálu ve větvi určené nastavením Default branch for manual and scheduled builds. Pokud existuje shoda, kanál se spustí, ale verze kanálu, která se spouští, může být v jiné větvi v závislosti na tom, jestli je aktivovaný kanál ve stejném úložišti jako dokončený kanál.

• Pokud jsou dva kanály v různých úložištích, spustí se aktivovaná verze kanálu ve větvi určené Default branch for manual and scheduled builds.
• Pokud jsou dva kanály ve stejném úložišti, spustí se verze aktivovaného kanálu ve stejné větvi jako aktivační kanál (s použitím verze kanálu z této větve v době splnění podmínky triggeru), i když se tato větev liší od Default branch for manual and scheduled builds, a to i v případě, že tato verze nemá filtry větví, které odpovídají dokončené větvi kanálu. Důvodem je to, že filtry větví z větve Default branch for manual and scheduled builds slouží k určení, jestli se má kanál spustit, a ne filtry větví ve verzi, která je v dokončené větvi kanálu.

Pokud se zdá, že se triggery dokončení potrubí neaktivují, zkontrolujte hodnotu Výchozí větev pro ruční a naplánovaná sestavení nastavení aktivovaného potrubí. Filtry pro větve ve verzi potrubí této větve slouží k určení, jestli spouštěč dokončení potrubí iniciuje běh potrubí. Ve výchozím nastavení je Default branch for manual and scheduled builds nastavená na výchozí větev úložiště, ale po vytvoření kanálu ji můžete změnit.

Typickým scénářem, kdy se spouštěč dokončení kanálu neaktivuje, je, když se vytvoří nová větev, filtry větví spouštěče dokončení kanálu se upraví tak, aby zahrnovaly tuto novou větev, ale když se první kanál dokončí ve větvi, která odpovídá novým filtrům, druhý kanál se nespustí. K tomu dochází v případě, že filtry větví ve verzi kanálu ve větvi Default branch for manual and scheduled builds neodpovídají nové větvi. Pokud chcete tento problém s triggerem vyřešit, máte následující dvě možnosti.

• Aktualizujte filtry větví v kanálu ve větvi Default branch for manual and scheduled builds tak, aby odpovídaly nové větvi.
• Aktualizujte nastavení Výchozí větev pro manuální a plánované sestavení na větev, která má verzi pipeline s filtry větví odpovídající nové větvi.

Kombinování typů aktivačních událostí

Když v kanálu zadáte triggery CI i triggery kanálu, můžete očekávat, že se nová spuštění spustí při každém odeslání, které odpovídá filtrům triggeru CI, a spuštění zdrojového kanálu, které odpovídá filtrům triggeru dokončení kanálu.

Představte si například dva kanály s názvem A a B, které jsou ve stejném úložišti, oba mají triggery CI a B má trigger dokončení kanálu nakonfigurovaný pro dokončení kanálu A. Pokud provedete vložení do úložiště:

• Spustí se nové spuštění A na základě triggeru CI.
• Současně se zahájí nový běh B na základě spouštěcího mechanismu CI. Toto spuštění využívá artefakty z předchozího spuštění pipeline A.
• Po dokončení A spustí další spuštění Bna základě triggeru dokončení potrubí v B.

Chcete-li zabránit aktivaci dvou spuštění B v tomto příkladu, je nutné zakázat spouštěč CI (trigger: none) nebo spouštěč pipeline (pr: none).