[JIRA] (JENKINS-38109) Parallel variable expansion
Title: Message Title Daniel Stone closed an issue as Not A Defect Jenkins / JENKINS-38109 Parallel variable expansion Change By: Daniel Stone Status: Resolved Closed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38109) Parallel variable expansion
Title: Message Title Daniel Stone commented on JENKINS-38109 Re: Parallel variable expansion Sorry, you're totally right; I'd realised very shortly after posting this that it had nothing to do with parallel itself but block capture/evaluation at best. 'def' of the variable to reduce scope hadn't occurred to me, but makes total sense. Apologies for the noise. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38109) Parallel variable expansion
Title: Message Title
Daniel Stone updated an issue
Jenkins / JENKINS-38109
Parallel variable expansion
Change By:
Daniel Stone
I was previously using parallel with a hardcoded set of platforms, to trigger further jobs:{noformat}expanded = { "platform 1": { build(job: "platform-1") }, "platform 2": { build(job: "platform-2") }}{noformat}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:{noformat}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{noformat}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:{noformat}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') }{noformat}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. Delaying 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.
Add Comment
[JIRA] (JENKINS-38109) Parallel variable expansion
Title: Message Title
Daniel Stone updated an issue
Jenkins / JENKINS-38109
Parallel variable expansion
Change By:
Daniel Stone
I was previously using parallel with a hardcoded set of platforms, to trigger further jobs:{noformat}expanded = { "platform 1": { build(job: "platform-1") }, "platform 2": { build(job: "platform-2") }}{noformat}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:{noformat}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{noformat}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:{noformat}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') }{noformat}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.Delaying string expansion, i.e. calculating the variable and then passing build(job: job_name), doesn't work any better.
Add Comment
[JIRA] (JENKINS-38109) Parallel variable expansion
Title: Message Title
Daniel Stone updated an issue
Jenkins / JENKINS-38109
Parallel variable expansion
Change By:
Daniel Stone
I was previously using parallel with a hardcoded set of platforms, to trigger further jobs: {noformat} expanded = { "platform 1": { build(job: "platform-1") }, "platform 2": { build(job: "platform-2") } } {noformat} 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: {noformat} 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/${ platform name } -${arch} ", propagate: true, wait: true)} }}parallel expanded {noformat} 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: {noformat} 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') } {noformat} 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. Delaying string expansion, i.e. calculating the variable and then passing build(job: job_name), doesn't work any better.
Add Comment
[JIRA] (JENKINS-38109) Parallel variable expansion
Title: Message Title
Daniel Stone created an issue
Jenkins / JENKINS-38109
Parallel variable expansion
Issue Type:
Improvement
Assignee:
Jesse Glick
Components:
workflow-cps-plugin
Created:
2016/Sep/09 4:38 PM
Priority:
Minor
Reporter:
Daniel Stone
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/${platform} -$ {arch} ", 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.
