Aufeinanderfolgendes Auslösen von Pipelines

  • Artikel

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

Große Produkte verfügen über mehrere Komponenten, die voneinander abhängig sind. Diese Komponenten werden häufig unabhängig voneinander erstellt. Wenn sich eine Upstream Komponente (z. B. eine Bibliothek) ändert, müssen die Downstreamabhängigkeiten neu erstellt und überprüft werden.

Fügen Sie in solchen Situationen einen Pipelinetrigger hinzu, um Ihre Pipeline nach erfolgreichem Abschluss der auslösenden Pipeline auszuführen.

Hinweis

Zuvor haben Sie möglicherweise zum klassischen Editor für Ihre YAML-Pipeline navigiert und Buildabschlusstrigger auf der Benutzeroberfläche konfiguriert. Obwohl dieses Modell weiterhin funktioniert, wird es nicht mehr empfohlen. Der empfohlene Ansatz besteht darin, Pipelinetrigger direkt in der YAML-Datei anzugeben. Buildabschlusstrigger, wie im klassischen Editor definiert, haben verschiedene Nachteile, die jetzt in Pipelinetriggern behoben wurden. Für instance gibt es keine Möglichkeit, eine Pipeline auf demselben Branch wie die der auslösenden Pipeline mithilfe von Buildabschlusstriggern auszulösen.

Konfigurieren von Pipelineressourcentriggern

Um eine Pipeline nach Abschluss einer anderen Pipeline auszulösen, konfigurieren Sie einen Pipelineressourcentrigger .

Im folgenden Beispiel wird ein Pipelineressourcentrigger so konfiguriert, dass eine Pipeline namens app-ci ausgeführt wird, nachdem eine Ausführung der security-lib-ci Pipeline abgeschlossen wurde.

Dieses Beispiel enthält die folgenden beiden Pipelines.

  • security-lib-ci – Diese Pipeline wird zuerst ausgeführt.

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

  • app-ci – Diese Pipeline verfügt über einen Pipelineressourcentrigger, der die app-ci Pipeline so konfiguriert, dass sie bei jeder Ausführung der security-lib-ci Pipeline automatisch ausgeführt wird.

    # 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 gibt den Namen der Ressourcendatei an. Verwenden Sie die hier definierte Bezeichnung, wenn Sie auf die Pipelineressource aus anderen Teilen der Pipeline verweisen, z. B. wenn Sie Pipelineressourcenvariablen verwenden oder Artefakte herunterladen.
  • source: security-lib-ci gibt den Namen der Pipeline an, auf die von dieser Pipelineressource verwiesen wird. Sie können den Namen einer Pipeline aus dem Azure DevOps-Portal an mehreren Stellen abrufen, z. B. auf der Pipelines-Startseite. Standardmäßig werden Pipelines nach dem Repository benannt, das die Pipeline enthält. Informationen zum Aktualisieren des Namens einer Pipeline finden Sie unter Pipelineeinstellungen. Wenn die Pipeline in einem Ordner enthalten ist, schließen Sie den Ordnernamen ein, einschließlich des führenden \, z. B \security pipelines\security-lib-ci. .
  • project: FabrikamProject – Wenn sich die auslösende Pipeline in einem anderen Azure DevOps-Projekt befindet, müssen Sie den Projektnamen angeben. Diese Eigenschaft ist optional, wenn sich sowohl die Quellpipeline als auch die ausgelöste Pipeline im selben Projekt befinden. Wenn Sie diesen Wert angeben und Ihre Pipeline nicht ausgelöst wird, lesen Sie den Hinweis am Ende dieses Abschnitts.
  • trigger: true – Verwenden Sie diese Syntax, um die Pipeline auszulösen, wenn eine Version der Quellpipeline abgeschlossen ist. In den folgenden Abschnitten in diesem Artikel erfahren Sie, wie Sie filtern, welche Versionen der Quellpipeline abgeschlossen werden, um eine Ausführung auszulösen. Wenn Filter angegeben werden, muss die Quellpipelineausführung mit allen Filtern übereinstimmen, um eine Ausführung auszulösen.

Wenn die auslösende Pipeline und die ausgelöste Pipeline dasselbe Repository verwenden, werden beide Pipelines mit demselben Commit ausgeführt, wenn eine die andere auslöst. Dies ist hilfreich, wenn Ihre erste Pipeline den Code erstellt und die zweite Pipeline ihn testet. Wenn die beiden Pipelines jedoch unterschiedliche Repositorys verwenden, verwendet die ausgelöste Pipeline die Version des Codes in dem Branch, der durch die Default branch for manual and scheduled builds Einstellung angegeben wird, wie unter Überlegungen zu Verzweigung von Pipelineabschlusstriggern beschrieben.

Hinweis

In einigen Szenarien enthält refs/heads die Standardbranch für manuelle Builds und geplante Builds kein Präfix. Beispielsweise kann die Standardbranch auf main statt auf refs/heads/mainfestgelegt werden. In diesem Szenario funktioniert ein Trigger aus einem anderen Projekt nicht. Wenn beim Festlegen project auf einen anderen Wert als den der Zielpipeline Probleme auftreten, können Sie die Standardbranch so aktualisieren, dass sie eingeschlossen refs/heads wird, indem Sie den Wert in einen anderen Branch ändern und ihn dann wieder auf die Standardbranch ändern, die Sie verwenden möchten.

Das Konfigurieren von Pipelineabschlusstriggern wird in YAML-Vorlagen nicht unterstützt. Sie können Pipelineressourcen weiterhin in Vorlagen definieren.

Branchfilter

Optional können Sie angeben, welche Branches beim Konfigurieren des Triggers eingeschlossen oder ausgeschlossen werden sollen. Wenn Sie Branchfilter angeben, wird eine neue Pipeline ausgelöst, sobald eine Ausführung der Quellpipeline erfolgreich abgeschlossen wurde, die den Branchfiltern entspricht. Im folgenden Beispiel wird die app-ci Pipeline ausgeführt, wenn der security-lib-ci auf einem beliebigen releases/* Branch abgeschlossen wird, mit Ausnahme von releases/old*.

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

Um die untergeordnete Pipeline für unterschiedliche Verzweigungen auszulösen, für die das übergeordnete Element ausgelöst wird, schließen Sie alle Verzweigungsfilter ein, für die das übergeordnete Element ausgelöst wird. Im folgenden Beispiel wird die app-ci Pipeline ausgeführt, wenn der security-lib-ci auf einem beliebigen releases/* Branch abgeschlossen wird, mit Ausnahme von releases/old*.

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

Hinweis

Wenn Ihre Branchfilter nicht funktionieren, versuchen Sie, das Präfix refs/heads/zu verwenden. Verwenden Sie z. B. refs/heads/releases/old* statt releases/old*.

Tagfilter

Die tags -Eigenschaft der trigger filtert, welche Pipelineabschlussereignisse Ihre Pipeline auslösen können. Wenn die auslösende Pipeline mit allen Tags in der tags Liste übereinstimmt, wird die Pipeline ausgeführt.

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

Hinweis

Die Pipelineressource verfügt auch über eine tags -Eigenschaft. Die tags-Eigenschaft der Pipelineressource wird verwendet, um zu bestimmen, aus welcher Pipeline ausgeführt werden soll, aus der Artefakte abgerufen werden sollen, wenn die Pipeline manuell oder durch einen geplanten Trigger ausgelöst wird. Weitere Informationen finden Sie unter Ressourcen: Pipelines und Auswertung der Artefaktversion.

Phasenfilter

Sie können Ihre Pipeline auslösen, wenn eine oder mehrere Phasen der auslösenden Pipeline abgeschlossen sind, indem Sie den stages Filter verwenden. Wenn Sie mehrere Phasen bereitstellen, wird die ausgelöste Pipeline ausgeführt, wenn alle aufgeführten Phasen abgeschlossen sind.

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.

Überlegungen zu Branches

Pipelineabschlusstrigger verwenden die Einstellung Standardbranch für manuelle und geplante Builds, um zu bestimmen, welche Branchversion der Branchfilter einer YAML-Pipeline ausgewertet werden soll, wenn ermittelt wird, ob eine Pipeline als Ergebnis des Abschlusses einer anderen Pipeline ausgeführt werden soll. Standardmäßig verweist diese Einstellung auf die Standardbranch des Repositorys.

Wenn eine Pipeline abgeschlossen ist, wertet die Azure DevOps-Runtime die Pipelineressourcentrigger-Branchfilter aller Pipelines mit Pipelineabschlusstriggern aus, die auf die abgeschlossene Pipeline verweisen. Eine Pipeline kann mehrere Versionen in verschiedenen Branches aufweisen, sodass die Laufzeit die Branchfilter in der Pipelineversion in der durch die Default branch for manual and scheduled builds -Einstellung angegebenen Branch auswertet. Wenn eine Übereinstimmung vorhanden ist, wird die Pipeline ausgeführt, aber die Version der ausgeführten Pipeline kann sich in einem anderen Branch befinden, je nachdem, ob sich die ausgelöste Pipeline im selben Repository wie die abgeschlossene Pipeline befindet.

  • Wenn sich die beiden Pipelines in unterschiedlichen Repositorys befinden, wird die ausgelöste Pipelineversion in dem von Default branch for manual and scheduled builds angegebenen Branch ausgeführt.
  • Wenn sich die beiden Pipelines im selben Repository befinden, wird die ausgelöste Pipelineversion in derselben Verzweigung wie die auslösende Pipeline gefahren (wobei die Version der Pipeline von der Verzweigung zum Zeitpunkt verwendet wird, an dem die Triggerbedingungen erfüllt sind), auch wenn sich diese Verzweigung sich von Default branch for manual and scheduled buildsunterscheidet und auch dann, wenn diese Version keine Branchfilter enthält, die mit dem Branch der abgeschlossenen Pipeline zusammenpassen. Dies liegt daran, dass die Branchfilter aus dem Default branch for manual and scheduled builds Branch verwendet werden, um zu bestimmen, ob die Pipeline ausgeführt werden soll, und nicht die Branchfilter in der Version, die sich im abgeschlossenen Pipelinebranch befindet.

Wenn Ihre Pipelineabschlusstrigger scheinbar nicht ausgelöst werden, überprüfen Sie den Wert der Einstellung Standardbranch auf manuelle und geplante Builds für die ausgelöste Pipeline. Die Branchfilter in der Version der Pipeline dieser Verzweigung werden verwendet, um zu bestimmen, ob der Pipelineabschlusstrigger eine Ausführung der Pipeline initiiert. Standardmäßig Default branch for manual and scheduled builds ist auf die Standardbranch des Repositorys festgelegt, Sie können es jedoch ändern, nachdem die Pipeline erstellt wurde.

Ein typisches Szenario, in dem der Pipelineabschlusstrigger nicht ausgelöst wird, ist, wenn ein neuer Branch erstellt wird. Die Branchfilter für den Pipelineabschlusstrigger werden so geändert, dass sie diesen neuen Branch einschließen, aber wenn die erste Pipeline in einem Branch abgeschlossen wird, der den neuen Branchfiltern entspricht, löst die zweite Pipeline nicht aus. Dies geschieht, wenn die Branchfilter in der Pipelineversion des Default branch for manual and scheduled builds Branchs nicht mit dem neuen Branch übereinstimmen. Sie haben die folgenden zwei Optionen, um dieses Triggerproblem zu beheben.

  • Aktualisieren Sie die Branchfilter in der Pipeline in der Default branch for manual and scheduled builds Verzweigung so, dass sie mit dem neuen Branch übereinstimmen.
  • Aktualisieren Sie die Einstellung Standardbranch für manuelle und geplante Builds auf einen Branch mit einer Version der Pipeline mit den Branchfiltern, die dem neuen Branch entsprechen.

Kombinieren von Triggertypen

Wenn Sie sowohl CI-Trigger als auch Pipelinetrigger in Ihrer Pipeline angeben, können Sie erwarten, dass jedes Mal neue Ausführungen gestartet werden, wenn ein Pushvorgang durchgeführt wird, der den Filtern des CI-Triggers entspricht, und eine Ausführung der Quellpipeline abgeschlossen wird, die den Filtern des Pipelineabschlusstriggers entspricht.

Nehmen wir beispielsweise zwei Pipelines mit dem Namen A und B im selben Repository an. Beide verfügen über CI-Trigger und B verfügen über einen Pipelineabschlusstrigger, der für den Abschluss der Pipeline Akonfiguriert ist. Wenn Sie einen Pushvorgang an das Repository durchführen:

  • Basierend auf dem CI-Trigger wird eine neue Ausführung von A gestartet.
  • Gleichzeitig wird ein neuer Lauf von B gestartet, basierend auf seinem CI-Auslöser. Bei dieser Ausführung werden die Artefakte aus einer vorherigen Ausführung der Pipeline Averwendet.
  • Nach A Abschluss der Ausführung wird basierend auf dem Pipelineabschlusstrigger in Beine weitere Ausführung von Bausgelöst.

Um zu verhindern, dass in diesem Beispiel zwei Ausführungen von B ausgelöst werden, müssen Sie dessen CI-Trigger (trigger: none) oder Pipelinetrigger (pr: none) entfernen.