Azure-devops-docs: Using azure-pipelines.yml of master branch to build feature branches is wrong!

[bravecobra]

There are multiple reasons why using the master version of azure-pipelines.yml to build other branches is wrong
Some use something like gitversion. Committing to master would affect the version of your app (which a feature should never do). Furthermore, the whole concept of branches is that changes in one branch doesn't affect another. Here that concept is violated!
If I build a feature branch, I expect it to use the version of azure-pipelines.yml in the same branch to build it.

The fact that only the master version is consider is the main reason why I would never use Azure-Devops!

Is there a way to the behaviour I expected in the first place?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 521b594c-dbb9-54d5-f56f-00e2f5fa1d92
• Version Independent ID: 509d3e4e-23db-8493-e1a6-acb67ec47e81
• Content: Building multiple branches - Azure Pipelines & TFS
• Content Source: docs/pipelines/build/ci-build-git.md
• Product: devops
• GitHub Login: @mlearned
• Microsoft Alias: mlearned

[vlef]

If I build a feature branch, I expect it to use the version of azure-pipelines.yml in the same branch to build it.

This is correct, and what you should be experiencing right now.

I found the documentation to not be very clear about this, but I don't think you are experiencing the correct behavior.

From my observations today, you do need a azure-pipelines.yml file in your master branch. When you create a branch and edit the azure-pipelines.yml within that new branch, the azure-pipelines.yml from your branch will be used for the build. So branches can have different build definitions.

Using conditions (eg: condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))) allows you to not have conflicts between branches and master when you want different build behaviors between some branches and master.

[exbarboss]

As I understand, you have 2 options create a giant yml config with all conditions for separate branches or use git merge strategies and use specific yml pipeline config per branch.

[bravecobra]

@vlef I was merely making the point that the documentation doesn't reflect that behavior. On the referenced page, there is no mention that when editing the azure-pipelines.yml in a branch, the build pipeline will be using that version of the file instead of the one in master, which was the conclusion I was taking after reading the docs.
You would want the file to be able to be used in multiple branches. It needs to be resilient to your branching model, but at the same time you don't want new 'code' to leak into the master branch just to run the build.
Can we have the documentation to at least reflect that behavior and maybe add some extra part on how and where the azure-pipelines.yml is being read from an build-agent perspective. In other words, how does a build-agent read your repository and/or azure-pipelines.yml when it's triggered?

[andyjlewis]

@bravecobra thanks for the feedback and I'm sorry about the delayed response. I'm pretty sure the essence of the content in topic you originally posted your issue about has been refactored into other topics. One of them is this one: https://docs.microsoft.com/azure/devops/pipelines/repos/github. Please see that and other topics under Repositories and feel free to raise another issue over there if you are not finding what you need.

[steved0x]

We have added a FAQ for this as well here and also a few mentions in some other places like the one linked above. In short, it is the yaml file in the branch that is being pushed that is used.

[jons-aura]

What about manually triggered builds? I can't find anything in the linked documentation about which definition YAML is used when manually building a branch with an updated YAML file. From our testing it appears to be using the master branch definition still in that case.