I have a single project but with two "master" branches.
master
virt/master
Each of them would have their own azure-pipeline.yml specific for their branch.
The first pipeline in master has the trigger set up as
trigger:
batch: true
branches:
include:
- refs/heads/master
The second one is in the virt/master branch.
trigger:
batch: true
branches:
include:
- refs/heads/virt/master
Here's the repository that I am experimenting on https://dev.azure.com/trajano/experiments/_git/multi-branch
master build https://dev.azure.com/trajano/experiments/_build?definitionId=11
virt/master build https://dev.azure.com/trajano/experiments/_build?definitionId=12
The problem I am having is when I push a change to the virt/master branch both pipelines get executed
Am I missing something in my configuration? Or is this a bug on Azure Devops?
I also tried to exclude but to no avail.
trigger:
batch: true
branches:
include:
- refs/heads/master
exclude:
- refs/heads/virt/master
If you want to have separate pipelines please create separate file definition for them. I think that your configuration is fine and the issue is that you share the same file as definition.
When I moved to separate file it works as expected:
To create different pipelines for different branches. You need to rename the azure-pipelines.yml file in virt/master branch or create a new yml file with the some contents and with a different name. And create pipeline multi-branch(virt) from this new yml file.
If both pipelines are created from the yaml file with the same name azure-pipeline.yml. And the azure-pipeline.yml file exists in both of the branches. Then they are identical pipelines(even though the azure-pipeline.yml file contents might be different).
You can see from above screen. Pipeline multi-branch and multi-branch(virt) were building the same virt/master branch(using the tasks in the azure-pipeline.yml of virt/master). If you push to master branch. You will see both pipelines will be triggered to build master branch(using the tasks in the azure-pipeline.yml of master). Pipeline multi-branch and multi-branch(virt) are one pipeline
See this thread for more information.
Related
trigger:
branches:
include:
- master
tags:
include:
- Showcase
pr:
branches:
include:
- master
the code above is from my yaml azure pipeline with using bitbucket repo. Anytime I do a PR in my bitbucket repository I expect build pipeline to run automatically in azure devops but it's not the case. Currently, I have to run the pipeline manually to complete PR validation. creating pipeline with the same line of code under another repo works correctly. I'm not sure what the problem is.
I created anoter dummy pipeline with a new project, the pr triggered build automatically when pr to the the master. the webhohook seems to be working fine. the trigger option doesn't override the yaml pipeline. I can't think of anything else to check.
On a migration from gitlab to azure, we need to specify triggers. I have a pipeline on my main (azure-pipelines.yml) which describes the pipeline, I have a trigger condition
trigger:
- none
pr:
branches:
include:
- main
This is purely to make sure that after the merge to main has happened, the pipeline is triggered.
However, if I create any feature to this repo, I create a new branch ( featureX) from master and it will have the same azure-pipelines.yml file. On this branch, I would like the SW to be built for every commit I do to that branch ( featureX). So it makes sense to have the trigger in the branch ( featureX) as follows:
trigger:
branches:
include:
- '*'
Now when the merge is ready, is it a best practise to delete the pipeline file from the featureBranch or do we change the trigger in the yml file of featureBranch?
Or is it handled in a way which I did not mention here?
So you want to trigger a build for every PR and for any feature branches?
If I understand that correctly, keep a single azure-pipelines.yml file and just add a branch trigger:
trigger:
branches:
include:
- feature/*
pr:
branches:
include:
- main
Quite new to the CI/CD pipelines in AzDO. I was going through some official Azure Pipeline documents where I have some doubts on Schedule Triggers.
Below is a pipeline Snippet in main branch:
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- main
- releases/*
exclude:
- releases/ancient/*
- cron: "0 12 * * 0"
displayName: Weekly Sunday build
branches:
include:
- releases/*
always: true
The documentation says the Pipeline will run for branches "main" and "releases" at midnight if there has been some changes to those branches since the last successful scheduled run and build the "releases" branch on sunday irrespective of changes to releases branch which seems understandable.
Which means we can control other branches (e.g. releases) to build from YAML file present in another branch (e.g. main).
Again, the documentation also states, for below YAML in a release branch
# YAML file in the release branch
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- main
The pipeline won't build "release" branch since the branch name is missing under "branches" section. But will it build the "main" branch though since it's mentioned under "branches" section?
If no, then how can the first YAML in main branch make "releases" branches to build? Does the YAML file in main/default branch has some special capabilities?
If yes, does it really make sense to build "main" branch from release/non-main branches?
Thanks in advance.
If no, then how can the first YAML in main branch make "releases"
branches to build? Does the YAML file in main/default branch has some
special capabilities?
There's a setting for default branch in Azure Pipelines (Edit pipeline -> get sources -> Default branch for manual and scheduled builds) which tells the pipeline which branch to evaluate for scheduled runs. Yaml builds use the same scheduling that classic pipelines do and a changes to the yaml-file in that default branch are reflected in the scheduler.
Or to put it in another way, a pipeline in Azure DevOps is a separate thing from the yaml-file in repository. After creating a yaml-file in repo, you need to create a pipeline in Azure DevOps, via new pipeline -> select repo -> existing Azure Pipelines yaml file (or create a new yaml file). This step creates the actual pipeline, which has it's own configurations that are stored somewhere in Azure DevOps database. Those configurations point to the yaml file that is evaluated for pipeline runs and when the file is changed.
If you queue a pipeline manually, and select some other branch than the default, the yaml file in the branch that you selected is evaluated. Also, when evaluating branch triggers, pipeline evaluates the yaml file in the branch commit is made to. So, if you have this trigger in main branch:
trigger:
- main
- feature/*
And this in feature/foo -branch:
trigger:
- main
A commit to the feature/foo branch does not trigger the pipeline.
(Not sure if I answered the question clearly or just added some confusion, but there you go. The trigger implementation in Azure Pipelines is a bit confusing at first.)
When a pipeline is created it must be specified its file path and branch. When this pipeline runs a branch is asked again. What is the purpose of this second branch? My initial thought was that the branch where my code is located and the branch where the Yaml file is located are two different things.
However, it seems, after some issues, that when I select a branch in the Run pipeline dialog both the Yaml file and the source code are checked out from this same branch. Is it correct?
Thanks for any help.
This is the expected behavior.
In Azure Devops, the location of the Yaml file is in the branch of the repo, so thehe executed yaml file and the source branch are synchronized.
The first operation of selecting a branch is used to create the pipeline, if you run directly for the first time, you don’t need to choose the execution branch.
When you run a DevOps pipeline(select execution branch), you choose a branch to execute the pipeline. The Yaml file in that branch is the one that will be executed by default and the pipeline will checkout the source code from the same branch.
The version that gets executed will be determined by which branch you're running the pipeline for.
If you want to checkout the source files of other branches in a yaml file, you need to add an additional repo source.
For example:
resources:
repositories:
- repository: TestRepo
ref: refs/heads/branchname
type: git
name: Projectname/RepoName
stages:
- stage: deploy
jobs:
- job: test
steps:
- checkout: TestRepo
CI doesn't trigger when I change anything in my feature/* branch. I configured a YAML on Azure pipeline -
trigger:
branches:
include:
- feature/*
I also tried the other style of configuration - again unsuccessful
trigger:
- feature/*
Also tried with the complete feature name like feature/my-feature
However when I override the YAML trigger and use branch filters to point to the specific feature branch the CI works when I make changes in the branch.
I followed this official documentation
Azure Pipelines - CI Trigger on feature branch doest work with YAML
You should set the yaml file in one of branch under the feature folder.
Since you set the trigger with feature/*, but there is no branch named feature, we could not set the the yaml file in feature brance of the repo. So, we need to set the the yaml file in one of branch under the feature folder, like: feature/Test.
In this case, when I change anything in my feature/* branch, like feature/Test2, it will trigger this pipeline.
Hope this helps.
the one reason this could happen - the yaml file is not present in the feature branch. the decision to trigger the build or not comes when a commit is pushed to a branch, based on the content of the yaml file in the branch. if the file is not there, obviosuly nothing will be built.