-
Improvement
-
Resolution: Not A Defect
-
Minor
-
None
I was previously using parallel with a hardcoded set of platforms, to trigger further jobs:
expanded = { "platform 1": { build(job: "platform-1") }, "platform 2": { build(job: "platform-2") } }
However, I wanted to be able to reuse the same YAML definition I already use for job creation (via jenkins-job-builder). Having to mark YAML import as explicitly non-CPS is awkward, and the lack of closure support is also awkward, but the following still seemed like an improvement on a hardcoded (and large) list of platforms:
for (int i = 0; i < platform_list.size(); i++) { platform = platform_list[i] for (int j = 0; j < arch_list.size(); j++) { arch = arch_list[j] name = "${platform}-${arch}" expanded[name] = { build(job: "build/${name}", propagate: true, wait: true) } } } parallel expanded
Unfortunately, it seems like these blocks all resolve lazily: the key side of the map is populated correctly along both axes, however each block resolves to the same job, e.g. I have:
parallel 'debian-jessie-x86-64': { build(job: 'build/ubuntu-14.04-x86-64') } parallel 'fedora-24-x86-64': { build(job: 'build/ubuntu-14.04-x86-64') } parallel 'ubuntu-14.04-x86-64': { build(job: 'build/ubuntu-14.04-x86-64') }
This is really a downer; I'd rather not be hardcoding my axes in the job-run matrices as well as the per-job definitions, given that there are a few places using this.
Avoiding string expansion for a set variable instead, i.e. calculating the variable and then passing build(job: job_name), doesn't work any better.