Tentative de déclenchement d'un pipeline Azure lorsqu'un autre pipeline est terminé à l'aide d'un YAML. Il y a documentation indiquant que vous pouvez ajouter une ressource de pipeline avec:
resources: # types: pipelines | builds | repositories | containers | packages
pipelines:
- pipeline: string # identifier for the pipeline resource
connection: string # service connection for pipelines from other Azure DevOps organizations
project: string # project for the source; optional for current project
source: string # source defintion of the pipeline
version: string # the pipeline run number to pick the artifact, defaults to Latest pipeline successful across all stages
branch: string # branch to pick the artiafct, optional; defaults to master branch
tags: string # picks the artifacts on from the pipeline with given tag, optional; defaults to no tags
Cependant, je n'ai pas pu comprendre ce que signifie la "source". Par exemple, j'ai un pipeline appelé myproject.myprogram
:
resources:
pipelines:
- pipeline: myproject.myprogram
source: XXXXXXXX
De plus, il n'est pas clair comment vous construirez un déclencheur basé sur cela.
Je sais que cela peut être fait à partir de l'interface graphique Web, mais il devrait être possible de le faire à partir d'un YAML.
Pour le déclenchement d'un pipeline à partir d'un autre responsable Azure docs suggérez cette solution ci-dessous. c'est-à-dire utiliser les déclencheurs de pipeline
resources:
pipelines:
- pipeline: RELEASE_PIPELINE // any arbitrary name
source: PIPELINE_NAME. // name of the pipeline shown on Azure UI portal
trigger:
branches:
include:
- dummy_branch // name of branch on which pipeline need to trigger
Mais en réalité, ce qui se passe, c'est qu'il déclenche deux pipelines comme prenons un exemple, supposons que nous ayons deux pipelines A et B et que nous voulons déclencher B lorsque A termine. dans ce scénario, B s'exécute 2 fois une lorsque vous effectuez un commit (parallèle à A) et une seconde après la fin de A.
donc pour éviter cela deux fois le problème d'exécution du pipeline, suivez la solution ci-dessous
trigger: none // add this trigger value to none
resources:
pipelines:
- pipeline: RELEASE_PIPELINE // any arbitrary name
source: PIPELINE_NAME. // name of the pipeline shown on Azure UI portal
trigger:
branches:
include:
- dummy_branch // name of branch on which pipeline need to trigger
en ajoutant trigger: aucun le deuxième pipeline ne se déclenchera pas au démarrage de la validation et ne se déclenchera que lorsque le travail sera terminé pour la première fois.
J'espère que cela vous aidera.
Les ressources ne sont pas destinées au déclencheur de fin de génération. selon le docs le déclencheur de fin de construction pas encore pris en charge dans la syntaxe YAML.
Après avoir créé le pipeline YAML, vous pouvez accéder à l'éditeur classique (cliquer sur settings
ou variables
) et y créer le déclencheur.
Modifier:
Maintenant, vous devez cliquer sur les "déclencheurs":
Puis:
Deuxième édition:
Microsoft a ajouté cette fonctionnalité également le YAML :) voir ici :
# this is being defined in app-ci pipeline
resources:
pipelines:
- pipeline: security-lib
source: security-lib-ci
trigger:
branches:
- releases/*
- master
Dans l'exemple ci-dessus, nous avons deux pipelines - app-ci et security-lib-ci. Nous souhaitons que le pipeline app-ci s'exécute automatiquement chaque fois qu'une nouvelle version de la bibliothèque de sécurité est créée dans master ou dans une branche de publication.
Microsoft documentation dit que YAML est l'approche préférée. Donc, au lieu d'aller pour l'option build-trigger, comprenons le déclencheur YAML, un peu déroutant. Les balises suivantes fonctionneront à partir de la question d'origine et maintenant avec une documentation un peu plus simple:
resources:
pipelines:
- pipeline: aUniqueNameHereForLocalReferenceCanBeAnything
project: projectNameNOTtheGUID
source: nameOfTheOtherPipelineNotTheDefinitionId
trigger:
branches:
include:
- master
- AnyOtherBranch
La documentation de Microsoft prête à confusion et les identifiants sont nombreux. Parfois, ils veulent le projet GUID parfois le nom du projet. Parfois, ils veulent le nom du pipeline et parfois l'ID de définition du pipeline. Mais ils utilisent le même nom pour la variable (projet et pipeline Et en plus de cela, ils écrivent une documentation qui ne permet pas de deviner facilement laquelle utiliser le mieux est de faire des essais et des erreurs.
Je pense que pour éviter la confusion dans d'autres endroits, je donne l'exemple d'un autre endroit dans le pipeline, vous vous référez aux mêmes variables avec des valeurs différentes. Dans la tâche DownloadArtifact, vous devez utiliser le projet GUID et l'ID de définition de pipeline comme indiqué ci-dessous:
- task: DownloadPipelineArtifact@2
inputs:
source: specific (a literal constant value not the pipeline name)
project: projectGUIDNOTtheProjectName
pipeline: numericDefinitionIdOfPipelineNotPipelineNameOrUniqueRef
runVersion: 'latest'
Regardez simplement comment ils ont utilisé les mêmes variables d'une manière différente, mais en se référant tous les deux à un pipeline et dans mon cas au même pipeline exact. Cela pourrait créer de la confusion et pour éviter de tomber sur le prochain problème, je le donne ici pour clarification.