web-dev-qa-db-fra.com

Azure Pipeline pour déclencher Pipeline à l'aide de YAML

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.

8
Alex Kaszynski

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.

2
Sunny Goel

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":

enter image description here

Puis:

enter image description here

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.

6
Shayki Abramczyk

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.

4
SijuMathew