Our second monorepo (I know, I know! :) ) maintains several (like, up to a dozen or so) long-running release branches so we can do long-term support.
We name our branches like releases/* (the master for one particular unreleased version to land changes into), in-flight/* (for in-flight releases), bugfix/*, feature/*, hotfix/*.
It would be great to be able to prioritise build scheduling in a way that takes into account branch names. For example, activity on a hotfix/ branch should be prioritised higher than bugfix/ or feature/, since there's probably an urgency to it. We'd also want to favour builds on older releases/10.* compared to releases/12.* for some internal reasons. We'd want to prioritise deployment/release activity over "regular development" activity, for another example.
Having the ability to prioritise based on branch name would allow us to avoid needing to run isolated agents for particular use-cases to react to sporadic demand but be idle most of the time, which would make our hosting cheaper.
Our second monorepo (I know, I know! :) ) maintains several (like, up to a dozen or so) long-running release branches so we can do long-term support.
We name our branches like
releases/*
(themaster
for one particular unreleased version to land changes into),in-flight/*
(for in-flight releases),bugfix/*
,feature/*
,hotfix/*
.It would be great to be able to prioritise build scheduling in a way that takes into account branch names. For example, activity on a
hotfix/
branch should be prioritised higher thanbugfix/
orfeature/
, since there's probably an urgency to it. We'd also want to favour builds on olderreleases/10.*
compared toreleases/12.*
for some internal reasons. We'd want to prioritise deployment/release activity over "regular development" activity, for another example.Having the ability to prioritise based on branch name would allow us to avoid needing to run isolated agents for particular use-cases to react to sporadic demand but be idle most of the time, which would make our hosting cheaper.