1cdfc9ce47
Co-authored-by: Antoine Martin <dev@ayakael.net> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Michael Simons <msimons@microsoft.com> Co-authored-by: Chris Rummel <crummel@microsoft.com> Co-authored-by: Marc Paine <marcpop@microsoft.com> Co-authored-by: Logan Bussell <loganbussell@microsoft.com> Co-authored-by: NET Source-Build Bot <102560831+dotnet-sb-bot@users.noreply.github.com> Co-authored-by: vseanreesermsft <78103370+vseanreesermsft@users.noreply.github.com> Co-authored-by: Jason Zhai <v-wuzhai@microsoft.com> Co-authored-by: v-wuzhai <46013274+v-wuzhai@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Matt Mitchell <mmitche@microsoft.com>
57 lines
No EOL
2.6 KiB
YAML
57 lines
No EOL
2.6 KiB
YAML
# Select a pool provider based off branch name. Anything with branch name containing 'release' must go into an -Svc pool,
|
|
# otherwise it should go into the "normal" pools. This separates out the queueing and billing of released branches.
|
|
|
|
# Motivation:
|
|
# Once a given branch of a repository's output has been officially "shipped" once, it is then considered to be COGS
|
|
# (Cost of goods sold) and should be moved to a servicing pool provider. This allows both separation of queueing
|
|
# (allowing release builds and main PR builds to not intefere with each other) and billing (required for COGS)
|
|
# Additionally, the pool provider name itself may be subject to change when the .NET Core Engineering Services
|
|
# team needs to move resources around and create new and potentially differently-named pools. Using this template
|
|
# file from an Arcade-ified repo helps guard against both having to update one's release/* branches and renaming.
|
|
|
|
# How to use:
|
|
# This yaml assumes your shipped product branches use the naming convention "release/..." (which many do).
|
|
# If we find alternate naming conventions in broad usage these can be added to the condition below.
|
|
#
|
|
# First, import the template in an arcade-ified repo to pick up the variables, e.g.:
|
|
#
|
|
# variables:
|
|
# - template: /eng/common/templates/variables/pool-providers.yml
|
|
#
|
|
# ... then anywhere specifying the pool provider use the runtime variables,
|
|
# $(DncEngInternalBuildPool) and $ (DncEngPublicBuildPool), e.g.:
|
|
#
|
|
# pool:
|
|
# name: $(DncEngInternalBuildPool)
|
|
# demands: ImageOverride -equals windows.vs2019.amd64
|
|
|
|
variables:
|
|
# Coalesce the target and source branches so we know when a PR targets a release branch
|
|
# If these variables are somehow missing, fall back to main (tends to have more capacity)
|
|
|
|
# Any new -Svc alternative pools should have variables added here to allow for splitting work
|
|
- name: DncEngPublicBuildPool
|
|
value: $[
|
|
replace(
|
|
replace(
|
|
eq(contains(coalesce(variables['System.PullRequest.TargetBranch'], variables['Build.SourceBranch'], 'refs/heads/main'), 'release'), 'true'),
|
|
True,
|
|
'NetCore-Svc-Public'
|
|
),
|
|
False,
|
|
'NetCore-Public'
|
|
)
|
|
]
|
|
|
|
- name: DncEngInternalBuildPool
|
|
value: $[
|
|
replace(
|
|
replace(
|
|
eq(contains(coalesce(variables['System.PullRequest.TargetBranch'], variables['Build.SourceBranch'], 'refs/heads/main'), 'release'), 'true'),
|
|
True,
|
|
'NetCore1ESPool-Svc-Internal'
|
|
),
|
|
False,
|
|
'NetCore1ESPool-Internal'
|
|
)
|
|
] |