Déclencher un pipeline après l’autre

  • Article

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

Les produits volumineux contiennent plusieurs composants qui dépendent les uns des autres. Ces composants sont souvent générés indépendamment. Lorsqu’un composant en amont (une bibliothèque, par exemple) change, les dépendances en aval doivent être générées et validées à nouveau.

Dans des situations telles que celles-ci, ajoutez un déclencheur de pipeline pour exécuter votre pipeline quand le pipeline de déclenchement réussit.

Notes

Auparavant, vous avez peut-être accédé à l’éditeur classique pour votre pipeline YAML et configuré des déclencheurs d’achèvement de build dans l’interface utilisateur. Bien que ce modèle fonctionne toujours, il n’est plus recommandé. L’approche recommandée consiste à spécifier des déclencheurs de pipeline directement dans le fichier YAML. Les déclencheurs d’achèvement de build tels que définis dans l’éditeur classique présentent différents inconvénients, qui ont maintenant été traités dans les déclencheurs de pipeline. Par exemple, il n’existe aucun moyen de déclencher un pipeline sur la même branche que celle du pipeline de déclenchement à l’aide de déclencheurs d’achèvement de build.

Configurer des déclencheurs de ressources de pipeline

Pour déclencher un pipeline à l’achèvement d’un autre pipeline, configurez un déclencheur de ressource de pipeline.

L’exemple suivant configure un déclencheur de ressource de pipeline afin qu’un pipeline nommé app-ci s’exécute une fois l’exécution du pipeline security-lib-ci terminée.

Cet exemple contient les deux pipelines suivants.

  • security-lib-ci - Ce pipeline s’exécute en premier.

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

  • app-ci - Ce pipeline a un déclencheur de ressource de pipeline qui configure le pipeline app-ci pour qu’il s’exécute automatiquement chaque fois qu’une exécution du pipeline security-lib-ci est terminée.

    # 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 spécifie le nom de la ressource de pipeline. Utilisez l’étiquette définie ici lorsque vous faites référence la ressource de pipeline à partir d’autres parties du pipeline, par exemple lors de l’utilisation de variables de ressource de pipeline ou du téléchargement d’artefacts.
  • source: security-lib-ci spécifie le nom du pipeline référencé par cette ressource de pipeline. Vous pouvez récupérer le nom d’un pipeline à partir du portail Azure DevOps à plusieurs endroits, tels que la page d’arrivée des pipelines. Par défaut, les pipelines sont nommés d'après le référentiel qui les contient. Pour mettre à jour le nom d’un pipeline, consultez les Paramètres du pipeline. Si le pipeline est contenu dans un dossier, incluez le nom du dossier, y compris le premier \, par exemple \security pipelines\security-lib-ci.
  • project: FabrikamProject - Si le pipeline de déclenchement se trouve dans un autre projet Azure DevOps, vous devez spécifier le nom du projet. Cette propriété est facultative si le pipeline source et le pipeline déclenché se trouvent dans le même projet. Si vous spécifiez cette valeur et que votre pipeline ne se déclenche pas, consultez la note à la fin de cette section.
  • trigger: true - Utilisez cette syntaxe pour déclencher le pipeline quand une version du pipeline source est terminée. Consultez les sections suivantes de cet article pour savoir comment filtrer quelles versions de l'achèvement du pipeline source déclencheront une exécution. Lorsque des filtres sont spécifiés, l’exécution du pipeline source doit correspondre à tous les filtres pour déclencher une exécution.

Si le pipeline de déclenchement et le pipeline déclenché utilisent le même référentiel, les deux pipelines s’exécutent à l’aide de la même validation quand l’un déclenche l’autre. Cela est utile si votre premier pipeline génère le code et le deuxième pipeline le teste. Toutefois, si les deux pipelines utilisent des référentiels différents, le pipeline déclenché utilisera la version du code dans la branche spécifiée par le paramètre Default branch for manual and scheduled builds, comme décrit dans les Considérations relatives aux branches pour les déclencheurs d’achèvement de pipeline.

Notes

Dans certains scénarios, la branche par défaut pour les builds manuelles et les builds planifiées n’inclut pas de préfixe refs/heads. Par exemple, la branche par défaut peut être définie à main la place de refs/heads/main. Dans ce scénario, un déclencheur d’un autre projet ne fonctionne pas. Si vous rencontrez des problèmes lorsque vous définissez project à une valeur différente de celle du pipeline cible, vous pouvez mettre à jour la branche par défaut pour inclure refs/heads en modifiant sa valeur pour une branche différente, puis en la ramenant à la branche par défaut que vous souhaitez utiliser.

La configuration des déclencheurs d’achèvement de pipeline n’est pas prise en charge dans les modèles YAML. Vous pouvez toujours définir des ressources de pipeline dans des modèles.

Filtres de branche

Vous pouvez éventuellement spécifier les branches à inclure ou exclure lors de la configuration du déclencheur. Si vous spécifiez des filtres de branche, un nouveau pipeline est déclenché chaque fois qu'un pipeline source correspondant aux filtres de branche est exécuté avec succès. Dans l’exemple suivant, le pipeline app-ci s’exécute si le security-lib-ci se termine sur n’importe quelle branche releases/*, à l’exception de releases/old*.

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

Pour déclencher le pipeline enfant pour différentes branches pour lesquelles le parent est déclenché, incluez tous les filtres de branche pour lesquels le parent est déclenché. Dans l’exemple suivant, le pipeline app-ci s’exécute si le security-lib-ci se termine sur n’importe quelle branche releases/* ou la branche primaire, à l’exception de releases/old*.

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

Remarque

Si vos filtres de branche ne fonctionnent pas, essayez d’utiliser le préfixe refs/heads/. Par exemple, utilisez refs/heads/releases/old* à la place de releases/old*.

Filtres d'étiquette

La propriété tags des filtres trigger que les événements d’achèvement de pipeline peuvent déclencher votre pipeline. Si le pipeline de déclenchement correspond à toutes les balises de la liste tags, le pipeline s’exécute.

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

Notes

La ressource de pipeline a également une propriété tags. La propriété tags de la ressource de pipeline est utilisée pour déterminer l’exécution du pipeline à partir de laquelle récupérer des artefacts, lorsque le pipeline est déclenché manuellement ou par un déclencheur planifié. Pour plus d’informations, consultez Ressources : pipelines et Évaluation de la version de l’artefact.

Filtres de phase

Vous pouvez déclencher votre pipeline quand une ou plusieurs phases du pipeline de déclenchement sont terminées en utilisant le filtre stages. Si vous fournissez plusieurs phases, le pipeline déclenché s’exécute lorsque toutes les phases répertoriées sont terminées.

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.

Considérations sur les branches

Les déclencheurs d'achèvement de pipeline utilisent le paramètre de branche par défaut pour les builds manuelles et planifiées afin de déterminer la version des filtres de branche d'un pipeline YAML à évaluer lorsqu'il s'agit de déterminer si un pipeline doit être exécuté à la suite de l'achèvement d'un autre pipeline. Par défaut, ce paramètre pointe vers la branche par défaut du référentiel.

Lorsqu’un pipeline est terminé, le runtime Azure DevOps évalue les filtres de branche de déclencheur de ressource de pipeline de tous les pipelines avec des déclencheurs d’achèvement de pipeline qui référencent le pipeline terminé. Un pipeline peut avoir plusieurs versions dans différentes branches. Le runtime évalue donc les filtres de branche dans la version du pipeline dans la branche spécifiée par le paramètre Default branch for manual and scheduled builds. S’il existe une correspondance, le pipeline s’exécute, mais la version du pipeline qui s’exécute peut se trouver dans une branche différente en fonction du fait que le pipeline déclenché se trouve dans le même référentiel que le pipeline achevé.

  • Si les deux pipelines se trouvent dans des référentiels différents, la version de pipeline déclenchée dans la branche spécifiée par Default branch for manual and scheduled builds est exécutée.
  • Si les deux pipelines se trouvent dans le même référentiel, la version de pipeline déclenchée dans la même branche que le pipeline de déclenchement est exécutée (à l’aide du pipeline de cette branche au moment où la condition de déclenchement est remplie), même si cette branche est différente de Default branch for manual and scheduled builds, et même si cette version n’a pas de filtres de branche qui correspondent à la branche du pipeline achevé. Cela est dû au fait que les filtres de branche de la branche Default branch for manual and scheduled builds sont utilisés pour déterminer si le pipeline doit s’exécuter, et non les filtres de branche dans la version qui se trouve dans la branche de pipeline terminée.

Si vos déclencheurs d’achèvement de pipeline ne semblent pas se déclencher, vérifiez la valeur du paramètre de la branche par défaut pour le paramètre de builds manuelles et planifiées pour le pipeline déclenché. Les filtres de branche dans la version de cette branche du pipeline sont utilisés pour déterminer si le déclencheur d’achèvement du pipeline lance une exécution du pipeline. Par défaut, la Default branch for manual and scheduled builds est définie sur la branche par défaut du référentiel, mais vous pouvez la modifier après la création du pipeline.

Un scénario typique dans lequel le déclencheur d'achèvement de pipeline ne se déclenche pas est lorsqu'une nouvelle branche est créée, les filtres de branche du déclencheur d'achèvement de pipeline sont modifiés pour inclure cette nouvelle branche, mais lorsque le premier pipeline s'achève sur une branche qui correspond aux nouveaux filtres de branche, le second pipeline ne se déclenche pas. Cela se produit si les filtres de branche dans la version du pipeline dans la branche Default branch for manual and scheduled builds ne correspondent pas à la nouvelle branche. Pour résoudre ce problème de déclencheur, vous avez les deux options suivantes.

  • Mettez à jour les filtres de branche dans le pipeline dans la branche Default branch for manual and scheduled builds afin qu’ils correspondent à la nouvelle branche.
  • Mettez à jour le paramètre de Branche par défaut pour les builds manuelles et planifiées sur une branche qui a une version du pipeline avec les filtres de branche qui correspondent à la nouvelle branche.

Combinaison de types de déclencheurs

Lorsque vous spécifiez à la fois des déclencheurs de CI et des déclencheurs de pipeline dans votre pipeline, vous pouvez vous attendre à ce que de nouvelles exécutions soient lancées à chaque fois qu'un envoi (push) correspondant aux filtres du déclencheur CI est effectué, et qu'une exécution du pipeline source correspondant aux filtres du déclencheur d'achèvement du pipeline est achevée.

Par exemple, considérez deux pipelines nommés A et B qui se trouvent dans le même référentiel, tous deux ont des déclencheurs CI et B a un déclencheur d’achèvement de pipeline configuré pour l’achèvement du pipeline A. Si vous effectuez un envoi (push) vers le référentiel :

  • Une nouvelle exécution de A est lancée, sur la base de son déclencheur CI.
  • En même temps, une nouvelle exécution de B est lancée, sur la base de son déclencheur CI. Cette exécution consomme les artefacts d’une exécution précédente du pipeline A.
  • Une fois A terminé, il déclenche une autre exécution de B, en fonction du déclencheur d’achèvement du pipeline dans B.

Pour empêcher le déclenchement de deux exécutions de B dans cet exemple, vous devez désactiver son déclencheur CI (trigger: none) ou son déclencheur de pipeline (pr: none).