Reputation: 4542
For my main repository (let's say rmetzger/flink
), I would like to send Azure Pipelines build jobs to my own pool of agents running very powerful build machines.
For anybody who has forked my repository, I would like to run their build on the build machines provided by Azure.
To achieve that, I believe using Jobs and Conditions are the right approach.
I want to define two very similar jobs, each with a condition checking whether the repository is rmetzger/flink
or not.
This is the relevant part of my azure-pipelines.yml
file:
jobs:
- job: runOnStrongMachines
condition: eq(variables['Build.Repository.Name'], 'rmetzger/flink')
pool:
name: Default
steps:
- ...
- job: runOnAzure
condition: not(eq(variables['Build.Repository.Name'], 'rmetzger/flink'))
pool:
vmImage: 'ubuntu-latest'
steps:
- ...
Running this, variables['Build.Repository.Name']
always evaluates to null
, thus always the second job executes.
I fear that the predefined Build.Repository.Name
variable is scoped in a way that it is not accessible at this early phase of the build.
Upvotes: 0
Views: 472
Reputation: 19036
I fear that the predefined Build.Repository.Name variable is scoped in a way that it is not accessible at this early phase of the build.
YES, correct. Build.Repository.Name
could not be used at the early phase of build. And also, "the early phase of build" exactly means job level. In fact, the doc link you mentioned in the question has announced that this variable is agent-scoped:
As this doc described, this pre-defined variable Build.Repository.Name
can only be used in script/task level. And in your script, the scope of using this variable in Job condition is job-level instead of agent-level. That's why you receive the null
.
As work around, you can set the condition in every step/task
by using this variable Build.Repository.Name
. Or for convenient, add a step at the beginning to early-exit from the job.
Upvotes: 2