Partager via

Déclencher un pipeline à la suite de l'autre

  • Article

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

Les produits volumineux ont 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 reconstruites et revalidées.

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.

Remarque

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 les 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.

Les déclencheurs définis à l’aide de l’interface utilisateur des paramètres de pipeline sont prioritaires sur les déclencheurs YAML. Pour supprimer des déclencheurs planifiés par l’interface utilisateur d’un pipeline YAML, consultez Les paramètres de l’interface utilisateur remplacent les déclencheurs planifiés YAML.

Configurer des déclencheurs de ressources de pipeline

Pour déclencher un pipeline lors de l’achèvement d’un autre pipeline, configurez un déclencheur de ressources 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 ressources de pipeline ou lors 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 emplacements, tels que la page d’accueil Pipelines. Par défaut, les pipelines sont nommés en fonction du référentiel qui contient les pipelines. 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 \de début, 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 les deux pipelines, source et 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 lorsqu’une version du pipeline source s’achève. Consultez les sections suivantes de cet article pour découvrir comment filtrer quelles versions de l’achèvement du pipeline source déclencheront une exécution. Lorsque des filtres sont spécifiés, le processus 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écuteront en utilisant le même commit lorsque 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é utilise 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 considérations relatives aux déclencheurs d’achèvement du pipeline.

Remarque

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 sur main au lieu de refs/heads/main. Dans ce scénario, un déclencheur à partir d’un autre projet ne fonctionne pas. Si vous rencontrez des problèmes lorsque vous définissez project sur une valeur autre que celle du pipeline cible, vous pouvez mettre à jour la branche par défaut pour inclure refs/heads en modifiant sa valeur en une autre branche, puis en la remplaçant par 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 s’achève 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 s’achève sur n’importe quelle branche releases/* ou la branche principale, excepté pour 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*au lieu de releases/old*.

Filtres d’étiquettes

La propriété tags du trigger filtre les événements d’achèvement du pipeline qui peuvent déclencher votre pipeline. Si le pipeline déclencheur 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

Remarque

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 quel pipeline exécuter pour récupérer les 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 d’étape

Vous pouvez déclencher votre pipeline quand une ou plusieurs étapes du pipeline de déclenchement sont terminées à l’aide du filtre stages. Si vous fournissez plusieurs étapes, le pipeline déclenché s’exécute lorsque toutes les étapes 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 relatives à la branche

Les déclencheurs d’achèvement de pipeline utilisent le paramètre 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 qui doit être évaluée 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 achevé, 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 achevé. 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 selon 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 du pipeline déclenché dans la même branche que le pipeline de déclenchement est exécutée (en utilisant la version du pipeline de cette branche au moment où la condition de déclenchement est remplie), même si cette branche est différente de la 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 ceux des filtres de branche de la version se trouvant dans la branche du pipeline achevé.

Si vos déclencheurs d’achèvement de pipeline ne semblent pas se déclencher, vérifiez la valeur du paramètre Branche par défaut pour les 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, Default branch for manual and scheduled builds est défini sur la branche par défaut du référentiel, mais vous pouvez la modifier une fois le pipeline créé.

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

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

Combinaison de types de déclencheurs

Lorsque vous spécifiez à la fois des déclencheurs 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 push est effectué qui correspond aux filtres du déclencheur CI, et qu'une exécution du pipeline source est terminée qui correspond aux filtres du déclencheur de fin de pipeline.

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 démarrée, déclenchée par son déclencheur CI. Cette exécution utilise les artéfacts d’une exécution précédente du pipeline A.
  • Lorsque A s’achève, il déclenche une autre exécution de B, en fonction du déclencheur d’achèvement de 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).