I am running a test for a recently added feature (https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/sprint-159-update#cd-capabilities-for-your-multi-stage-yaml-pipelines), this is not working as expressed in the documentation (https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#pipeline-triggers-1).
Per the documentation, I am running the following test:
I have two files in the same repo (Azure Repo):
#azure-pipelines-a.yml
jobs:
- job: A
pool:
vmImage: ubuntu-18.04
steps:
- task: Bash@3
displayName: Test
inputs:
targetType: inline
script: |
echo "Running testa"
sleep 10
and
#azure-pipelines-b.yml
resources:
pipelines:
- pipeline: ci
source: testa
trigger:
branches:
- master
jobs:
- job: B
pool:
vmImage: ubuntu-18.04
steps:
- task: Bash@3
inputs:
targetType: inline
script: |
echo "Running testb"
Both pipelines are added to an Azure DevOps project.
From the documentation:
"""
When you specify both CI triggers and pipeline triggers, you can expect new runs to be started every time (a) an update is made to the repository and (b) a run of the upstream pipeline is completed. Consider an example of a pipeline B that depends on A. Let us also assume that both of these pipelines use the same repository for the source code, and that both of them also have CI triggers configured. When you push an update to the repository, then:
A new run of A is started.
At the same time, a new run of B is started. This run will consume the previously produced artifacts from A.
As A completes, it will trigger another run of B.
To prevent triggering two runs of B in this example, you must remove its CI trigger or pipeline trigger.
"""
Expected Result
azure-pipelines-a.yml should trigger azure-pipelines-b.yml after it has completed it's tasks.
Actual Result
Both pipelines run at the same time. Pipeline 'b' is not being triggered by pipeline 'a'.
Addition Information
These pipelines do not specify CI triggers, that said, the default behavior of CI triggers is to run; the documentation of pipeline triggers seems to indicate this behavior would be overwritten by the existence of the resource pipeline code, this is not the case.
Nor is the case when I have disabled CI triggers using:
trigger: none
In this case, the pipeline 'b' simply does not run in any automated fashion.
I have also tried a different configuration of the pipeline resource as such:
resources:
pipelines:
- pipeline: ci
source: testa
trigger: true
Using trigger: true in this case. This has also been unsuccessful in running as I understand the documentation indicates.
Having this feature would be ideal in cases where we want to separate the CI from the CD and allow independent executions of a deployment.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
running into the same issue, please considering update the documentation
Ahh, this explains why I could not get it working. Spent quite some time on it before I saw this post.
Thanks for pointing it out and Microsoft please update the docs.
I am struggling with this behavior as well. Pipelines triggers in YAML don't work as expected. 2 pipelines are triggered together and the second is not raised when first is finished.
Please share how we should approach these pipelines - is it a mistake in docs or bug inside the Azure DevOps.
Same problem here. Can't get a pipeline to be triggered by the completion of another no matter what I've tried in the resources block. Also, the example provided isn't particularly clear. Can we get an update on this please?
I was running into the same issue.
I found solution over here:
https://developercommunity.visualstudio.com/content/problem/864701/pipeline-trigger-not-working-as-expressed-in-docum.html?childToView=897210#comment-897210
In shortcut, when I've changed defaultBranch in my dependent pipeline to my working branch
triggering start working.:
You need to go: Edit -> Triggers (3 dots in right upper corner) -> YAML -> Get sources -> Default branch for manual and scheduled builds
Over there put a branch in which your yaml pipeline you are taking.
This helps me to work
That solution is less than ideal. No one would ever think that you'd have to go into the repo settings for a pipeline to change its default branch, when the pipeline was created on another branch.
That eventually worked for me.
Say local pipeline and (repo name) : pipe-A
remote pipeline (and repo): pipe-B
resources:
pipelines:
- pipeline: pipe-A (the one to be triggered)
source: pipe-B (the remote)
trigger:
branches:
- master (or whatever other branch)
However when I have multiple pipelines on master of repo A they are all triggered at the same time as a result of pipe-B completing.
Problem is I can't rename the actual pipeline and Azure DevOps simply gives it the name 'pipe-A (1)' if I have multiple pipeline yml files in the same branch which gives me headaches..
That eventually worked for me.
Say local pipeline and (repo name) : pipe-A
remote pipeline (and repo): pipe-Bresources: pipelines: - pipeline: pipe-A (the one to be triggered) source: pipe-B (the remote) trigger: branches: - master (or whatever other branch)However when I have multiple pipelines on master of repo A they are all triggered at the same time as a result of pipe-B completing.
Problem is I can't rename the actual pipeline and Azure DevOps simply gives it the name 'pipe-A (1)' if I have multiple pipeline yml files in the same branch which gives me headaches..
panoschatz: the - pipeline: value is a name that is used to reference the initial pipeline, it should not be the name of another pipeline. It's just like a variable name to use within the triggered pipeline. This is used, for instance, to allow you to download the artifacts from the initial pipeline.
I observed the same behavior as each commenter on this issue. I was curious about what was happening behind the scenes; I create my pipelines using the Azure DevOps extension for the Azure CLI (https://github.com/Azure/azure-devops-cli-extension), and even when stating the correct default branch for sourcing the yaml file, the downstream pipeline would not kick.
I noticed that it was only after after doing Edit -> Triggers (3 dots in right upper corner) -> YAML -> Get sources -> Default and _re-selecting_ the default branch that I specified as a command line argument _again_ that, oddly, it allowed me to save. The Edit view has a History tab that allows one to view the build definition diff between changes. A few revision and timestamp changes, but key is where there was once "options": null, now:
{
"options": [
{
"enabled": false,
"definition": {
"id": "5d58cc01-7c75-450c-be18-a388ddb129ec"
},
"inputs": {
"branchFilters": "[\"+refs/heads/*\"]",
"additionalFields": "{}"
}
},
{
"enabled": false,
"definition": {
"id": "a9db38f9-9fdc-478c-b0f9-464221e58316"
},
"inputs": {
"workItemType": "Bug",
"assignToRequestor": "true",
"additionalFields": "{}"
}
},
{
"enabled": false,
"definition": {
"id": "57578776-4c22-4526-aeb0-86b6da17ee9c"
},
"inputs": {}
}
],
# ...other stuff
I don't believe that these definition IDs are specific to me...one can easily google them and see that folks have hardcoded these values. In that array, I think the one with the branchFilters input is key, and specifically for the upstream pipeline (downstream does not require this change). I believe that this enables the upstream pipeline to send the triggering event to the downstream pipeline in the event of a branch filtering resource dependency.
Also...I can't believe that I spent hours trying to figure this out ðŸ˜
I didn't have time to wait for this to get resolved, so I used a combination of CI trigger (rather than pipeline trigger) and pipeline resource definitions to bring in metadata: https://github.com/MicrosoftDocs/vsts-docs/issues/3398#issuecomment-594635713
There is another important restriction on the use of pipeline triggers that I haven't seen mentioned here yet: it is necessary to publish an artifact on the triggering pipeline, otherwise the triggered pipeline won't kick.
I managed to have a minimum viable product for this, and I explained here how I have done it, with links to a repository and an Azure DevOps project. Hope it helps someone who's still struggling!
I was running into the same issue.
I found solution over here:
https://developercommunity.visualstudio.com/content/problem/864701/pipeline-trigger-not-working-as-expressed-in-docum.html?childToView=897210#comment-897210In shortcut, when I've changed defaultBranch in my dependent pipeline to my working branch
triggering start working.:
You need to go: Edit -> Triggers (3 dots in right upper corner) -> YAML -> Get sources -> Default branch for manual and scheduled builds
Over there put a branch in which your yaml pipeline you are taking.
This helps me to work
thank you very much, it works for me
I was running into the same issue.
I found solution over here:
https://developercommunity.visualstudio.com/content/problem/864701/pipeline-trigger-not-working-as-expressed-in-docum.html?childToView=897210#comment-897210In shortcut, when I've changed defaultBranch in my dependent pipeline to my working branch
triggering start working.:
You need to go: Edit -> Triggers (3 dots in right upper corner) -> YAML -> Get sources -> Default branch for manual and scheduled builds
Over there put a branch in which your yaml pipeline you are taking.
This helps me to work
This should be stated on the official Pipeline Trigger Documentation.
This is not a documentation problem... This a dev ops problem.
I want my pipeline number 2 to trigger on "master" and "staging"... nope, not possible. It has to match the Default Branch. Sure enough the work around works but now I have to have 2 pipelines... 1 for staging 1 for master. Dumb.
Most helpful comment
running into the same issue, please considering update the documentation