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
Related
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.)
I have a YAML build pipeline which resides on the repo PipelineRepo, branch master.
It contains a reference to a second repo AppRepo with a trigger on branch dev.
When a commit is made on AppRepo/dev, the build triggers and produces an artifact. The Build.SourceBranch predefined variable available during the build is of course dev as this was the triggering branch on AppRepo. This is as per the docs here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops#triggers
The specific part of the docs is this:
When an update to one of the repositories triggers a pipeline, then
the following variables are set based on triggering repository:
Build.Repository.ID
Build.Repository.Name
Build.Repository.Provider
Build.Repository.Uri
Build.SourceBranch
Build.SourceBranchName
Build.SourceVersion
Build.SourceVersionMessage
I consume the artifact in a Release pipeline, where I have a "Dev" stage with an artifact filter for branch dev:
I have a continuous deployment trigger on the artifact for branch dev:
Now we come to the problem
Every time a new build artifact is produced from the AppRepo/dev branch, the continuous deployment trigger doesn't fire because it thinks the build branch of the artifact was PipelineRepo/master. This is also true of the artifact filter on the stage - I have tested it by changing the continuous deployment trigger to master.
Note: you can see on the screenshot the build name contains the word "dev". This is because I use the Build.SourceBranch var in my custom build name. This proves the artifact is definitely produced by the AppRepo/dev triggering branch.
How can I get the DevOps Release Pipeline to pick up the triggering branch?
Based on your description, I could reproduce the similar issue in my organization.
When the pipeline is triggered by another repo branch, it still show the master branch in Release artifacts.
At the same time, the display of the trigger branch is also inconsistent in Pipelines.
For example:
Overview:
Detail view:
I suggest that you could create a feedback ticket in Our feedback Site.
For a workaround:
You could add a build tag in Pipeline to distinguish artifacts.
Yaml sample:
resources:
repositories:
- repository: test
type: git
name: 123/ARM
trigger:
- test
steps:
- checkout: test
- script: echo "##vso[build.addbuildtag]$(Build.SourceBranch)"
Release Pipeline:
You could set the master branch and add the build tag.
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.
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.
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.