44

Attempting to trigger an Azure pipeline when another pipeline has been completed using a YAML. There's documentation indicating that you can add a pipeline resource with:

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

However, I've been unable to figure out what the "source" means. For example, I have a pipeline called myproject.myprogram:

resources:
  pipelines:
  - pipeline: myproject.myprogram
    source: XXXXXXXX

Moreover, it's unclear how you'd build based a trigger based on this.

I know that this can be done from the web-GUI, but it should be possible to do this from a YAML.

Shayki Abramczyk
  • 36,824
  • 16
  • 89
  • 114
Alex Kaszynski
  • 1,817
  • 2
  • 17
  • 17

4 Answers4

52

For trigger of one pipeline from another azure official docs suggest this below solution. i.e. use pipeline triggers

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

But actually what happens, is that it triggers two pipelines. Take an example, let suppose we have two pipelines A and B and we want to trigger B when A finishes. So in this scenario B runs 2 times, once when you do a commit (parallel with A) and second after A finishes.

To avoid this two times pipeline run problem follow the below solution

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

By adding trigger:none second pipeline will not trigger at start commit and only trigger when first finish its job.

Hope it will help.

Charlie
  • 8,530
  • 2
  • 55
  • 53
Sunny Goel
  • 1,982
  • 2
  • 15
  • 21
  • 1
    This is a better answer. Thanks for adding it! – Alex Kaszynski Mar 24 '20 at 18:51
  • If your pipeline name includes spaces (e. g. My special build) then use: `- pipeline: WhatEverYouWant` and `source: My special build` With quotations `"` everything seems to be good, but the trigger worked for me only when I removed them. – BlackTuareg Sep 03 '20 at 09:39
  • Can we pass some parameters to second pipeline? – wesaw May 29 '23 at 07:57
  • Is the indentation for `branches` incorrect in these examples? Should `branches` be under the `trigger` key? – Jokinen Jul 28 '23 at 09:31
17

Microsoft documentation says that YAML is the preferred approach. So, instead of going for the build-trigger option let's understand the, little bit confusing, YAML trigger. The following tags will work from the original question and now with a bit easier documentation:

resources:
  pipelines:
  - pipeline: aUniqueNameHereForLocalReferenceCanBeAnything
    project: projectNameNOTtheGUID
    source: nameOfTheOtherPipelineNotTheDefinitionId
    trigger:
      branches:
        include:
        - master
        - AnyOtherBranch

The documentation from Microsoft is confusing and the IDs are numerous. At times they want the Project GUID at times the project name. At times they want the pipeline name and at times the pipeline definition Id. But they use the same name for the variable (project and pipeline). And on top of that they write documentation that does not make it easy to guess which one to use the best way is to trial and error.

I think to avoid the confusion in other places I'm giving example of another place in the pipeline you refer to the same variables with different values. In the DownloadArtifact task, you need to use the project GUID and the pipeline definition Id as shown below:

- task: DownloadPipelineArtifact@2
      inputs:
        source: specific (a literal constant value not the pipeline name)
        project: projectGUIDNOTtheProjectName
        pipeline: numericDefinitionIdOfPipelineNotPipelineNameOrUniqueRef
        runVersion: 'latest'

Just look at how they used the same variables in a different way, but both referring to a pipeline and in my case the same exact pipeline. That could create confusion and to avoid stumbling into the next issue I give it here for clarification.

SijuMathew
  • 342
  • 3
  • 12
  • 3
    Your first yaml snippet is what really helped me. I kept thinking that the documentation meant to put a code path and not the pipeline name within DevOps. The Microsoft document does a really bad job explaining the expected values in relation to code base and DevOps. – JBMac Feb 10 '20 at 18:48
14

The resources are not for the Build Completion trigger. according to the docs the build completion trigger not yet supported in YAML syntax.

After you create the YAML pipeline you can go to the classic editor (click on settings or variables) and there create the trigger.

Edit:

Now you need to click on the "Triggers":

enter image description here

And then:

enter image description here

Second Edit:

Microsoft added this feature also the YAML :) see here:

# this is being defined in app-ci pipeline
resources:
  pipelines:
  - pipeline: security-lib
    source: security-lib-ci
    trigger: 
      branches:
      - releases/*
      - master

In the above example, we have two pipelines - app-ci and security-lib-ci. We want the app-ci pipeline to run automatically every time a new version of the security library is built in master or a release branch.

Shayki Abramczyk
  • 36,824
  • 16
  • 89
  • 114
  • It looks like there's no longer the option to edit a yaml pipeline in the classic editor. Or am I missing something? – Ash Oct 28 '19 at 20:06
  • @Ash you can with the triggers options, see my edit. – Shayki Abramczyk Oct 28 '19 at 21:07
  • 1
    I have the same issue with the same question. I do not agree with the answer that the build trigger should be used because the [documentation][1] says that yaml is to be used and these are parameters mentioned. The issue is what does the parameter documentations mean. It did not make much sense to me. Maybe someone with experience with this can explain what Microsoft mean by this excellent documentation. [1]: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#pipeline-triggers-1 – SijuMathew Dec 30 '19 at 15:25
  • The trigger is apply on the master branch only, is there a way to apply on different branch? – Tamir Adler Dec 31 '19 at 09:14
  • @TamirAdler In the YAML you specify more branches, see the example above - `releases/*` – Shayki Abramczyk Dec 31 '19 at 09:15
  • @ShaykiAbramczyk I find that ADO YAML pipeline triggers don't fire for branches that have '/' forward slashes. Anyone had the same issue? – Paul Brittain Apr 22 '21 at 20:09
5

If you're not publishing an artifact from the triggering pipeline, it won't trigger the triggered pipeline.

Also, if the defaultBranch for manual and scheduled builds in the triggered pipeline is not the same as your working branch, the triggered pipeline won't kick in at the end of the triggering pipeline execution.

I have created a minimum viable product for a pipeline trigger, and I explain better the two issues I just mentioned in this answer.

ccoutinho
  • 3,308
  • 5
  • 39
  • 47
  • You state that if you're not publishing an artifact from the triggering pipeline, it won't trigger the triggered pipeline. That is what I thought to be true as well and am sure I read it in docs.microsoft but now I have a pipeline which we added a nightly schedule trigger and some long running tasks and conditions to prevent the publish steps so that it won't make an artifact and when it completes, its triggering the release pipeline. Microsoft is saying that's expected behavior. If you can point me to where you found that documented, I'd really appreciate it. – cResults Feb 17 '22 at 14:22
  • As far as I remember, I didn't find it documented, that's why it took me so long to figure this out. It's possible that, in the meantime, MS has changed that, and made it work without publishing the artifact – ccoutinho Feb 17 '22 at 14:53
  • 1
    thank you for responding. Sounds like we are both getting some cuts on the bleeding edge of yaml pipelines :) – cResults Mar 14 '22 at 17:50
  • 1
    This answer has been really helpful for me as I wasn't getting my downstream pipeline to trigger until I started publishing an artifact (just a dummy one in my case, to make it work). So, I can confirm that this is still an issue. We're on ADO Server 2020 - perhaps people who do not find the artifact to be necessary are on a later version now? – Bob Mar 13 '23 at 09:39
  • 1
    Undervalued answer; Especially if you are working on a feature branch - invaluable! – Carlos Soriano May 22 '23 at 13:48