0

Anybody know if it is possible to pass in a repo name / base the build on a dynamic repo name? This would allow us to share the same build definition across different branches, cutting down on definitions when creating a feature branch, etc.

When using a TFVC repo we would store the different releases in the same repo but different paths. We could reuse the same build definition across different releases/FB's by altering the source path such as $/product/$(release)/......

It appears Git likes to have the repo hard-coded into the build (hence the dropdown - no way to plug in a variable.

While the question is targeted to On-prem Azure DevOps, if it is possible in the hosted environment it would be helpful to know.

enter image description here

Amittai Shapira
  • 3,749
  • 1
  • 30
  • 54
John Hennesey
  • 343
  • 1
  • 2
  • 18
  • 1
    Not completely following your question. When you use GIT, you are configuring the build pipeline for the repo. If you were to create multiple branches (develop, Release\1.0, Release\1.1, etc) that build definition would apply to any branches that you create. You can setup the CI triggers to start on "*" so that a push of any branch will start the build pipeline. – Matt Jul 17 '20 at 13:16
  • Perfect! This is what I was after. I thought the get sources was limited to what it was set up with - ie. master. I branched, modified the branch, set the CI sources to modify the branch in question and it worked. Thanks! – John Hennesey Jul 17 '20 at 15:32

3 Answers3

2

I recommend using YAML build templates. By default these check out "self" and are stored in the repo. That way they work on forks, branches etc. Each branch can contain tweaks to the build process as well.

With the 'old' UI based builds this isn't possible.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
1

What you are looking for is actually two things:

  • templates - this allows you reuse definition accross different pipelines
  • triggers - this allows you to trigger pipeline when commit happens on different branches
Krzysztof Madej
  • 32,704
  • 10
  • 78
  • 107
  • Triggers did it. I was incorrectly assuming that if a build was set up for master it would only monitor master. Once I branched and set CI to monitor both branches (master, r1) the build kicked off for both and gathered the proper sources. – John Hennesey Jul 17 '20 at 15:33
  • Cool. What is also worth to know. If you make a change on build definition on some feature branch it will apply only to this feature branch leaving all branches with original definition until you will merge it. Can you consider upvoting my reply if it was helpful for you? – Krzysztof Madej Jul 18 '20 at 04:38
0

Looks like Task Groups solved the need (mostly). I was hoping to have one build definition that could be shared across multiple branches; while this appears to be possible on the hosted model, on prem is different.

I am able to clone a build (or use templates) to have an entry point into the repo/branch to get the sources, then pass off the work to a common task group. If I need to modify the build process for multiple branches, just modify the task group.

John Hennesey
  • 343
  • 1
  • 2
  • 18
  • If you are starting from scratch, I'd look at trying to implement the YAML builds as jesshouwing recommended. Not sure which version on-premise you are, but I'm pretty sure it was there in AzDo Server 2019. If not, there is a RC1 out of server 2020 that I'm almost positive would have majority of recent improvements. – Matt Jul 17 '20 at 16:38