In my main branch, I have the trigger property in the azure-pipeline.yml looking at the main branch only
trigger:
- main
I then created another branch called test-pipeline and in that branch, I updated the trigger to include everything:
trigger:
- '*'
Then I built the test-pipeline branch using Azure Pipeline.
Now every time I push a commit to the test-pipeline branch, the Azure Pipeline build is triggered. How does that work? I thought Azure Pipeline only looks at the main branch for config?
How does that work? I thought Azure Pipeline only looks at the main
branch for config?
No, Azure Pipelines reads the build defintion from the commits you push, not from any specific branch.
When you create a new pipeline you select a repository and specify the name of a file which includes your build definition (usually azure-pipeline.yml)
Once the pipeline is setup Azure Pipelines will evaluate every commit that is pushed to the repository. It will look into the triggers specified in azure-pipeline.yml for that particular commit and decide whether or not to start the pipeline.
What is happening in your case is that you are pushing a commit where the trigger is set to '*', which means regardless of what branch it will trigger a build
Related
I have a Azure Devops build pipeline that has multiple branch triggers. I am using a wildcard to capture changes to branches under refresh/4.*. An example of a branch that I am targeting in this case would be refresh/4.13.0-refresh. But, the wildcard trigger is not firing when I push new refresh branches.
Here is the trigger definition yml
trigger:
branches:
include:
- dev
- refs/tags/4.*
- release/4.x
- nightly-build
- refresh/4.*
I was expecting this definition to trigger the build action when a new branch such as refresh/4.9.1-refresh is pushed to the remote repo. All of the other branch triggers here are succeeding. My hunch is that - could be treated as a delimiter. But, I tried updating the trigger to refresh/4.*-refresh with no success.
The definition seems correct but is the - refresh/4.* line also present in the yml from your refresh/4.13.0-refresh branch? If it's a new change to the yml that is only in the main branch for example, then it wouldn't trigger yet.
In Azure Devops, when i view a branch Repos->Branches->Select a branch i was able to click Set up build.
However, i am not able to choose an existing pipeline there.
When i select a pipeline Pipeline->Edit->Triggers i can add Branch filters aswell as path filters, however those do not take effect.
I tried to add filters for release/my-release aswell as release/* or a path-filter release.
I want to be able to start a pipeline from the Branch overview. What do i have to do?
If you're using YAML pipelines, e.g. azure-pipeline.yml, make sure this file is also available in your branch.
If the pipeline YAML was added to main after you've branched the release branches, the build will never trigger. Because the branch doesn't have the pipeline YAML .
Furthermore the triggers of the YAML should be specified in the YAML instead of Pipeline->Edit->Triggers.
Example:
trigger:
branches:
include:
- master
- release/*
Don't forget to turn off the "Override the YAML continuous integration trigger from here" Option:
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.
In Azure Devops, I have a repo that's in Bitbucket. I'd like to trigger a package publish on every approved pr that gets merged to the develop branch.
I've figured out how to conditionally run a task if the build is a pr or not, and how to trigger if the pr is to develop, but that means that the task is run for every PR created to develop. I'd like the task to only run when the pr has been merged to develop.
I noticed the following variables in my pipeline:
SYSTEM_PULLREQUEST_ISFORK=False
SYSTEM_PULLREQUEST_MERGEDAT=
SYSTEM_PULLREQUEST_PULLREQUESTID=139
SYSTEM_PULLREQUEST_PULLREQUESTNUMBER=139
SYSTEM_PULLREQUEST_SOURCEBRANCH=source-branch
SYSTEM_PULLREQUEST_SOURCECOMMITID=e55835e7e2e65ad87fd09a03959fefcfcc4d475f
SYSTEM_PULLREQUEST_SOURCEREPOSITORYURI=[repoURL]
SYSTEM_PULLREQUEST_TARGETBRANCH=develop
And the SYSTEM_PULLREQUEST_MERGEDAT= variable stood out. Anyone have suggestions? Am I overly complicating this?
It is possible to achieve this with just conditions. Let's say you were merging from feature branch to develop branch. And you only want a task to be executed when the pr has been merged to develop.
First of all you should know the default CI triggers and PR triggers for Bitbucket repository on Azure pipeline.
1, CI triggers
If you don't specify any triggers, the default is as if you wrote below, which means commit to any branch will trigger the pipeline.
trigger:
branches:
include:
- '*'
When you specify a trigger, it replaces the default implicit trigger, and only pushes to branches that are explicitly configured to be included will trigger a pipeline. Includes are processed first, and then excludes are removed from that list.
2, PR triggers
If no pr triggers appear in your YAML file, pull request validations are automatically enabled for all branches.
When you specify a pr trigger, it replaces the default implicit pr trigger, and only pushes to branches that are explicitly configured to be included will trigger a pipeline.
Each new run builds the latest commit from the source branch of the pull request. This is different from how Azure Pipelines builds pull requests in other repositories (e.g., Azure Repos or GitHub), where it builds the merge commit,
See the document for more information.
So if you don't specify any CI triggers or PR Triggers. The default behavior is to enable the triggers for all branches. And the PR triggers will only trigger the pipeline to build the last commit from the source branch(ie. Feature branch) instead of develop branch.
So it will explain why there are two triggered builds on an update to a pr. one is CI trigger(ie. IndividualCI), another is PullRequest. Both builds were against the source branch (ie.feature).
When the pr was merged to develop. what happened was a new commit being added to develop branch, which will trigger the CI build. So the task you want to trigger should be run against develop branch.
As for above case of yours. I suggest you disable the pr triggers and only enable the CI triggers.(for pr triggers will only build the latest commit from the source branch, which is the same with CI trigger. )
You can disable the pr trigger like below:
pr: none
So you can just set the condition like below for the task
- task: taskname
input:
condition: and(eq(variables['Build.SourceBranchName'], 'develop'), eq(variables['Build.Reason'], 'IndividualCI'))
You can also use Webhook to trigger the azure pipeline. And set the condtion to eq(variables['Build.Reason'], 'ResourceTrigger')
resources:
webhooks:
- webhook: bitbucketwebhook
connection: bitbucketwebhook
Please see this thread for more information.
I'm setting up Azure DevOps pipeline for CI for a .NET Core 3.0 mvc project.
I've created a new branch, DEVOPS, that I would like to store the YAML file in. The file includes a trigger for changes to the master branch:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
# other steps/tasks below...
I deleted all files except .gitignore and azure-pipelines.yml from the DEVOPS branch, committed it, and pushed it to origin (Az DevOps Repo).
I then switched to the master branch, deleted the azure-pipelines.yml file, committed, and pushed.
this did not trigger the pipeline
Then I made a change to one of the views in master, committed, and pushed.
this also did not trigger the pipeline
So, how can I configure Azure DevOps Pipelines to store the azure-pipelines.yml file in a branch other than master, and trigger on changes to master?
According to your operation steps and the YAML configuration, the build could not be triggered is reasonable.
Let's focus on the YAML configuration first. In you YAML definition, you set master as trigger branch. This means only changes occurred on master can trigger this build pipeline.
In your first action, you delete some files from DEVOPS branch. Then commit and push it into remotes/Origin. But, as what you defined in pipeline, this action could not trigger this pipeline. This is as expect.
Next, in master branch, you delete the azure-pipelines.yml file, then commit and push it. Note, at this time, the remote master branch has been sync with the local master branch. In one word, after you push to origin, no azure-pipelines.yml file exists in the master branch of Azure Devops.
BUT, whether the build can run depends on whether yml exists or not. Yeah, you have made some changes on master branch. But without yml file, the build could not be ran successfully. That's why you encountered the pipeline did not be triggered.
And, same reason for your next action.
How can I configure Azure DevOps Pipelines to store the
azure-pipelines.yml file in a branch other than master, and trigger on
changes to master?
Until now, this could not be achieve if what's your build definition type is YAML.
For the pipeline which definition type is YAML, to achieve what you expect, the yml file with the same configuration must also stored in the relevant branches which be defined in the pipeline.
Take the example you described in the question. If you only store the yml file in DEVOPS branch, no matter do any changes on master branch, it will never trigger the build.
To achieve trigger on changes to master, this yml file must also stored in master branch. So, the pre-condition of build pipeline which definition type is YAML can be triggered is, the yml file must also exists in the relevant branches if it is listed in the yml definition. This because, this build type can run based on the yml from source files.