My YAML file does not have any triggers configured, so it runs on every commit, which I am happy with. But it also runs every time I create a new branch. As this code is identical to that which it was branched from, there is no point to this, and it is rolling my build numbers, without any new work actually being done. Is there a way to skip the build pipeline on branch creation?
According to the official documentation:
Here is the behavior when you push a new branch (that matches the branch filters) to your repository:
If your pipeline has path filters, it will be triggered only if the new branch has changes to files that match that path filter.
If your pipeline does not have path filters, it will be triggered even if there are no changes in the new branch.
So, I would try to include some path filters to your trigger, but the way they cover all files. It could be something like this:
trigger:
paths:
include:
- */*
Or, in case the above include filter doesn't work, you can try to build an exclude filter, which will also mean "all files included", like:
trigger:
paths:
exclude:
- non_existing_folder/*
I don't have the Azure DevOps env at my expose to try this out right now, but hope you get the idea.
Related
I have some Azure YAML pipelines that I need to trigger in a chain. I am finding that the documented approach does not seem to work. I have tried various things recommended in other SO posts: Azure Pipeline to trigger Pipeline using YAML and Azure DevOps unable to trigger yaml pipeline off of completed build.
I also know they had open bugs for some of this so not sure if I am missing something or if the feature is broken now?
For sake of brevity, I have two pipelines named "MyProject.Common" and "MyProject.Foo". I want Foo to run after Common succeeds.
A snippet of my yaml is below. Note that here are some things I have already tried:
Not including the first "trigger: none" line.
Including "trigger: true" after the "source:" bit, instead of the "branches: include:... piece".
Tried is with "branches: include: - '*' "
And various other things. MyProject.Foo is just not being triggered.
I have also verified that there are no CI triggers under the Edit -> Triggers menu.
Have also verifies that MyProject.Common is publishing a build artifact.
Any ideas? If this is a broken feature, what would be a good workaround?
Snippet:
trigger: none
resources:
pipelines:
- pipeline: 'MyProject.Common'
source: 'MyProject.Common'
trigger:
branches:
include:
- main
- refs/head/main
Branch triggers and Pipeline resource triggers are very similar but have one very big difference - how and where the trigger is evaluated.
Branch triggers get evaluated for every branch.
Pipeline resource triggers get evaluated ONLY On the pipeline Default branch.
from the docs:
Pipeline completion triggers use the Default branch for manual and scheduled builds setting to determine which branch's version of a YAML pipeline's branch filters to evaluate when determining whether to run a pipeline as the result of another pipeline completing. By default this setting points to the default branch of the repository.
source
What does this mean?
Your pipeline resource trigger yaml changes need to be in default branch of the pipeline that you want to be triggered. You can do this by merging your changes into the default branch, or changing the default branch to your dev/feature branch by following these instructions.
I am not at all sure why, but I deleted the dependent pipeline and created a new one (referencing the original yaml file) and it then triggered properly.
I can only guess that Azure lost some type of reference behind the scenes as the YAML for the trigger was accurate.
Thanks for all the input. It was helpful even though it didn't solve the main issue.
I'm trying to develop a pipeline from feature-branch.
sample-code:
trigger:
branches:
include:
- deploy-pipeline/sql/test/*
exclude:
- deploy-pipeline/pipeline/*
- deploy-pipeline/sql/sample_scripts/*
Here deploy-pipeline is the name of the feature branch. I have azure-pipeline.yml file in the feature branch. I want to deploy only sql scripts inside deploy-pipeline/sql/test/ so i have included it in the include flag, whenever there's any change in sql/test folder the pipeline should trigger automatically and deploy sql scripts to my test environment. Once I tested this functionality working as expected then I can push this pipeline structure to master to deploy sql scripts only in specific folder.
I tested pushing changes to the sql/test folder, sample sql scripts. But the pipeline isn't triggering automatically. Not sure where I'm missing it. Please help me.
In trigger branches, what you need to write is the name of your branch. If your branch name is deploy-pipeline/sql/test, you don't need to write /* behind it to indicate every files in the branch.
In the other words, you just need to write the branch name in trigger, then every thing in the branch can trigger the pipeline.
So the script should be like this:
trigger:
branches:
include:
- deploy-pipeline/sql/test
exclude:
- deploy-pipeline/pipeline
- deploy-pipeline/sql/sample_scripts
I guess you might be confusing path triggers with branch triggers. Only branch names can be written in the branch trigger and only path can be written in the path trigger.
Click CI triggers for detailed information and examples.
I've a single repository having visual studio solution(.sln), where I've more than one project(.csproj) in same solution(i.e. WebAPI project, WebApp project etc.)...
Now, I've created separate pipeline(s) for individual project, which trigger whenever any commit comes to my XYZ branch...(ex. through PR code merge from feature to XYZ branch)
Now, the issue is...
Whenever any commit come to any project in that repository all pipeline start building there respective projects... Here I just want to build a specific project pipeline for which the commit file(s) comes into...
You can specify file paths to include or exclude.
# specific path build
trigger:
branches:
include:
- master
- releases/*
paths:
include:
- docs
exclude:
- docs/README.md
When you specify paths, you must explicitly specify branches to trigger on. You can't trigger a pipeline with only a path filter; you must also have a branch filter, and the changed files that match the path filter must be from a branch that matches the branch filter.
Check here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers
Is it possible to schedule a yaml pipeline using tags. What I want to achive, is an easy way to specify which commit to build. For this system, it needs to be rebuild on each deploy. I would like to not use branches for this as I would like to avoid merging when I need to deploy a new version.
Ultimately, I would put the tag name in a variable for easy update. It also seems tags work with triggers, but I can't get it to work with schedules.
I tried something like this, but nothing happens. If I change refs/tags/release-20200907-4 with master, it works
schedules:
- cron: "*/5 * * * *"
always: true
branches:
include:
- refs/tags/release-20200907-4
It looks that this is not possible. Following documentation:
Scheduled triggers evaluation
Scheduled triggers are evaluated for a branch when the following events occur.
A pipeline is created.
A pipeline's YAML file is updated, either from a push, or by editing it in the pipeline editor.
A pipeline's YAML file path is updated to reference a different YAML file. This change only updates the default branch, and therefore will only pick up schedules in the updated YAML file for the default branch. If any other branches subsequently merge the default branch, for example git pull origin master, the scheduled triggers from the newly referenced YAML file are evaluated for that branch.
A new branch is created.
After one of these events occurs in a branch, any scheduled runs for that branch are added, if that branch matches the branch filters for the scheduled triggers contained in the YAML file in that branch.
and since documentation clearly refers only to the branches not to tags and test proves that this doesn't work for tags, there is no way to achieve what you want. Even trigger evaluation is triggered by a new branch, and not a new tag.
You may consider adding this a feature request on developer community.
I'm working for the first time with Azure Devops Pipelines. I'm using a .yml file. But I can't figure out why the pipeline won't run when I checkout and push a branch from develop to "releases/*. It just won't trigger even when there are changes in src/ which are inside my new releases/newbranch
But when I merge my change from "customers/feature-branch" with customers/moa-prototype-client1/release the pipeline will run.
My trigger is:
trigger:
branches:
include:
- customers/moa-prototype-client1/release
- releases/*
paths:
include:
- src/*
- src/customers/moa-prototype-client1/*
exclude:
- '*.yml'
- src/customers/*
What can cause this?
So in short: It will trigger when I merge from Customers/Customername/Develop to Customers/Customername/Release. But won't when I merge from Develop to Releases/*
Our repo:Gitflow
From your description, it seems that this issue exists in the Release/* branch. And the customers branch could work as expected.
During my testing, I encounter a similar situation. If the Release/* branch doesn't contain the Yaml file with triggers, the changes in the release branches will not trigger the build.
For example:
Doesn't work
To solve this issue, you could copy the same yaml file from other branches to all release branches.
Then the changes in the Release branches could trigger the build successfully.
On the other hand, as Kontekst said, the Path filters are case-sensitive. You could check them at the same time.
Hope this helps
Solution: After checking the links and possible solution some users suggested, I got it to work. But I was not totaly happy whit this fix, because I wanted to run my pipeline though my .yml file and not override my triggers though the pipeline settings.
When I looked at my .yml again and noticed a space behind releases/*, I removed this space and committed this to my repo and all was working as it should!