Clean up BuildTools servicing branch build definitions
dagood opened this issue · 1 comments
I recently noticed that the master/"standard" BuildTools build definition more recently built the BuildTools release/2.0.0 branch than the build definition we set up to service release/2.0.0. The commands needed to do a BuildTools build don't change much over time, so the two are compatible, but the "standard" build def changed the BuildTools dotnet/versions paths. I don't want to thrash between the two defs, so I disabled the 2.0.0 build def for now. (I made it throw an error telling you to use the master def.)
I'm not sure what the state of our release/1.0.0 and release/1.1.0 branch builds are.
I think we should fork the definition for each release branch and turn on triggers, so it's never normal to manually queue a BuildTools build. Then a human doesn't have to guess which build def is supposed to build which branch.
// Auto-generated message
Going forward, the .NET team is using https://github.com/dotnet/arcade to develop the code and issues formerly in this repository. Feel free to reopen/move this issue if it still applies to servicing branches in this repository, or source code which now resides in the Arcade repository.