[JIRA] (JENKINS-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title Ivan Martinez commented on JENKINS-49904 Re: workflow-cps groovy engine hijacks closure.rehydrate() Any news on this issue? Is there any workaround to rehydrate a Closure without using the rehydrate method from the Closure class itself? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.188893.1520200128000.5535.1578569220314%40Atlassian.JIRA.
[JIRA] (JENKINS-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title Benjamin Boyer commented on JENKINS-49904 Re: workflow-cps groovy engine hijacks closure.rehydrate() Has anyone managed to get through this problem OR is there any fix for it ? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title Andrew Bayer updated an issue Jenkins / JENKINS-49904 workflow-cps groovy engine hijacks closure.rehydrate() Change By: Andrew Bayer Labels: complex-cps-code global-lib groovy pipeline triaged-2018-11 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title
Logan Mzz commented on JENKINS-49904
Re: workflow-cps groovy engine hijacks closure.rehydrate()
I have same needs for same reason: having both a delegation DSL and access to script/definition-time scope.
mylib.pipeline { // <- call it 'pipeline' closure, only delegate to 'PipelineDSL'
init { // <- call it 'pipeline.init' closure, delegate to 'StageInitDSL'
// delegate == StageInitDSL@xx
// owner == pipeline
// this == WorkflowScript@xxx
echo 'blablabla...' // <- Not possible because, it's only accessible from 'script' scope
this.echo 'blablabla' // OK
}
}
Solution would be to set init.owner from pipeline.thisObject but it currently doesn't work:
class MyLib {
def pipeline(declaration) {
def stages = [init: {}]
def pipelineDSL = new PipelineDSL()
def stageDSL= new StageDSL()
pipelineDsl.init = { // it.delegate == declaration
// it.owner== declaration
// it.this == script
def fn = it.rehydrate(stageDSL, it.thisObject, it.thisObject)
fn.resolveStrategy = Closure.DELEGATE_FIRST
stages['init'] = fn // fn.delegate == stageDSL
// fn.owner== script
// fn.this == script
}
declaration.delegate = pipelineDSL
declaration.resolveStrategy = Closure.DELEGATE_ONLY
declaration()
stages.each { name, fn -> fn() }
}
}
def mylib = new MyLib()
mylib.pipeline {
init {
delegate // == declaration/pipeline <> script
owner // == declaration/pipeline <> script
this // == script
echo // Unknown property
mylib // Unknown property
this.echo // Ok
this.mylib // Ok
}
}
Add Comment
[JIRA] (JENKINS-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title Andrew Bayer commented on JENKINS-49904 Re: workflow-cps groovy engine hijacks closure.rehydrate() Gustaf Lundh - so from a preliminary investigation, the underlying problem here is something with Closure#clone(). If you just set the delegate on the closure (and the resolveStrategy, it works, but cloning somehow gets things stuck. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title Gustaf Lundh commented on JENKINS-49904 Re: workflow-cps groovy engine hijacks closure.rehydrate() Jesse Glick: Sorry for pinging you, but we are currently building a groovy framework/backend for pipeline jobs. The framework would allow our end users to setup and manage extremely complex pipelines, consisting of 100's of projects (and allow them to this in an reasonable easy way). Our original vision was very dependent on a working rehydrate() functionality. So before we restart the design work, I would like to know if you think this issue will be fixed within a reasonable timeframe (or if Cloudbees was already aware of the issue). Or perhaps this behaviour is by design? The Groovy and Cps implementation is still a bit too alien to allow me to fix the issue myself within a sensible timeframe. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title
Gustaf Lundh updated an issue
Jenkins / JENKINS-49904
workflow-cps groovy engine hijacks closure.rehydrate()
Change By:
Gustaf Lundh
workflow-cps-plugin's CpsScript breaks a fundamental Groovy language feature: closure.rehydrate(). In this short snippet of pipeline code we expect hydratedClosure() to run foo() successfully (which it does in a regular GroovyShell or Jenkins script console): {code:java}class TasksSpec implements Serializable {TasksSpec() {}def foo() {println this}def runClosure(closure) {def hydratedClosure = closure.rehydrate(this, this, this)hydratedClosure.resolveStrategy = Closure.DELEGATE_ONLYhydratedClosure() }}def tasksSpec = new TasksSpec()tasksSpec.runClosure() {foo()}{code} However, the Groovy Cps implementation seems to totally disregard the fact that we carry out a rehydrate() with the intention to execute the closure in the context of the tasksSpec object. Instead the closure is executed in the context of the WorkflowScript and fails with: {code:java}Java.lang.NoSuchMethodError: No such DSL method 'foo' found among steps [archive, bat, catchError, checkout, deleteDir, dir, echo, error, fileExists, getContext, git, isUnix, library, libraryResource, load, mail, node, parallel, pwd, readFile, retry, sh, sleep, stash, step, svn, timeout, tool, unarchive, unstash, waitUntil, withContext, withEnv, wrap, writeFile, ws] or symbols [all, always, apiToken, architecture, archiveArtifacts, artifactManager, batchFile, booleanParam, buildButton, buildDiscarder, caseInsensitive, caseSensitive, choice, choiceParam, clock, cloud, command, credentials, cron, crumb, defaultView, demand, disableConcurrentBuilds, downloadSettings, downstream, dumb, envVars, file, fileParam, filePath, fingerprint, frameOptions, freeStyle, freeStyleJob, fromScm, fromSource, git, headRegexFilter, headWildcardFilter, hyperlink, hyperlinkToModels, installSource, jdk, jdkInstaller, jgit, jgitapache, jnlp, jobName, junit, lastDuration, lastFailure, lastGrantedAuthorities, lastStable, lastSuccess, legacy, legacySCM, list, local, location, logRotator, loggedInUsersCanDoAnything, masterBuild, maven, maven3Mojos, mavenErrors, mavenMojos, mavenWarnings, modernSCM, myView, nodeProperties, nonStoredPasswordParam, none, paneStatus, parameters, password, pattern, pipelineTriggers, plainText, plugin, projectNamingStrategy, proxy, queueItemAuthenticator, quietPeriod, run, runParam, schedule, scm, scmRetryCount, search, security, shell, slave, sourceRegexFilter, sourceWildcardFilter, stackTrace, standard, status, string, stringParam, swapSpace, text, textParam, tmpSpace, toolLocation, unsecured, upstream, viewsTabBar, weather, zfs, zip] or globals [currentBuild, env, params] at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:176) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1280) at groovy.lang.MetaClassImpl.invokeMeth
[JIRA] (JENKINS-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title
Gustaf Lundh updated an issue
Jenkins / JENKINS-49904
workflow-cps groovy engine hijacks closure.rehydrate()
Change By:
Gustaf Lundh
workflow-cps-plugin's CpsScript breaks a fundamental Groovy language feature: closure.rehydrate(). In this short snippet of pipeline code we expect hydratedClosure() to run foo() successfully (which it does in a regular GroovyShell or Jenkins script console): {code:java}class TasksSpec implements Serializable {TasksSpec() {}def foo() {println this}def runClosure(closure) {def hydratedClosure = closure.rehydrate(this, this, this)hydratedClosure.resolveStrategy = Closure.DELEGATE_ONLYhydratedClosure() }}def tasksSpec = new TasksSpec()tasksSpec.runClosure() {foo()}{code} However, the Groovy Cps implementation seems to totally disregard the fact that we carry out a rehydrate() with the intention to execute the closure in the context of the tasksSpec object. ButiInstead Instead the closure is executed in the context of the WorkflowScript and fails with: {code:java}Java.lang.NoSuchMethodError: No such DSL method 'foo' found among steps [archive, bat, catchError, checkout, deleteDir, dir, echo, error, fileExists, getContext, git, isUnix, library, libraryResource, load, mail, node, parallel, pwd, readFile, retry, sh, sleep, stash, step, svn, timeout, tool, unarchive, unstash, waitUntil, withContext, withEnv, wrap, writeFile, ws] or symbols [all, always, apiToken, architecture, archiveArtifacts, artifactManager, batchFile, booleanParam, buildButton, buildDiscarder, caseInsensitive, caseSensitive, choice, choiceParam, clock, cloud, command, credentials, cron, crumb, defaultView, demand, disableConcurrentBuilds, downloadSettings, downstream, dumb, envVars, file, fileParam, filePath, fingerprint, frameOptions, freeStyle, freeStyleJob, fromScm, fromSource, git, headRegexFilter, headWildcardFilter, hyperlink, hyperlinkToModels, installSource, jdk, jdkInstaller, jgit, jgitapache, jnlp, jobName, junit, lastDuration, lastFailure, lastGrantedAuthorities, lastStable, lastSuccess, legacy, legacySCM, list, local, location, logRotator, loggedInUsersCanDoAnything, masterBuild, maven, maven3Mojos, mavenErrors, mavenMojos, mavenWarnings, modernSCM, myView, nodeProperties, nonStoredPasswordParam, none, paneStatus, parameters, password, pattern, pipelineTriggers, plainText, plugin, projectNamingStrategy, proxy, queueItemAuthenticator, quietPeriod, run, runParam, schedule, scm, scmRetryCount, search, security, shell, slave, sourceRegexFilter, sourceWildcardFilter, stackTrace, standard, status, string, stringParam, swapSpace, text, textParam, tmpSpace, toolLocation, unsecured, upstream, viewsTabBar, weather, zfs, zip] or globals [currentBuild, env, params] at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:176) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1280) at groovy.lang.MetaClass
[JIRA] (JENKINS-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title
Gustaf Lundh updated an issue
Jenkins / JENKINS-49904
workflow-cps groovy engine hijacks closure.rehydrate()
Change By:
Gustaf Lundh
workflow-cps-plugin's CpsScript breaks a fundamental Groovy language feature: closure.rehydrate(). In this short snippet of pipeline code we expect the closure hydratedClosure() to run foo() successfully (which it does in a regular GroovyShell or Jenkins script console) : {code:java}class TasksSpec implements Serializable {TasksSpec() {}def foo() {println this}def runClosure(closure) {def hydratedClosure = closure.rehydrate(this, this, this)hydratedClosure.resolveStrategy = Closure.DELEGATE_ONLYhydratedClosure() }}def tasksSpec = new TasksSpec()tasksSpec.runClosure() {foo()}{code} However, the Groovy Cps implementation seems to totally disregard the fact that we carry out a rehydrate() with the intention to execute the closure in the context of the tasksSpec object. ButiInstead the closure is executed in the context of the WorkflowScript and fails with: {code:java}Java.lang.NoSuchMethodError: No such DSL method 'foo' found among steps [archive, bat, catchError, checkout, deleteDir, dir, echo, error, fileExists, getContext, git, isUnix, library, libraryResource, load, mail, node, parallel, pwd, readFile, retry, sh, sleep, stash, step, svn, timeout, tool, unarchive, unstash, waitUntil, withContext, withEnv, wrap, writeFile, ws] or symbols [all, always, apiToken, architecture, archiveArtifacts, artifactManager, batchFile, booleanParam, buildButton, buildDiscarder, caseInsensitive, caseSensitive, choice, choiceParam, clock, cloud, command, credentials, cron, crumb, defaultView, demand, disableConcurrentBuilds, downloadSettings, downstream, dumb, envVars, file, fileParam, filePath, fingerprint, frameOptions, freeStyle, freeStyleJob, fromScm, fromSource, git, headRegexFilter, headWildcardFilter, hyperlink, hyperlinkToModels, installSource, jdk, jdkInstaller, jgit, jgitapache, jnlp, jobName, junit, lastDuration, lastFailure, lastGrantedAuthorities, lastStable, lastSuccess, legacy, legacySCM, list, local, location, logRotator, loggedInUsersCanDoAnything, masterBuild, maven, maven3Mojos, mavenErrors, mavenMojos, mavenWarnings, modernSCM, myView, nodeProperties, nonStoredPasswordParam, none, paneStatus, parameters, password, pattern, pipelineTriggers, plainText, plugin, projectNamingStrategy, proxy, queueItemAuthenticator, quietPeriod, run, runParam, schedule, scm, scmRetryCount, search, security, shell, slave, sourceRegexFilter, sourceWildcardFilter, stackTrace, standard, status, string, stringParam, swapSpace, text, textParam, tmpSpace, toolLocation, unsecured, upstream, viewsTabBar, weather, zfs, zip] or globals [currentBuild, env, params] at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:176) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1280) at groovy.lang.Me
[JIRA] (JENKINS-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title
Gustaf Lundh updated an issue
Jenkins / JENKINS-49904
workflow-cps groovy engine hijacks closure.rehydrate()
Change By:
Gustaf Lundh
workflow-cps-plugin's CpsScript breaks a fundamental Groovy language feature: closure.rehydrate(). In this short snippet of pipeline code we expect hydratedClosure() to run foo() successfully (which it does in a regular GroovyShell or Jenkins script console) : {code:java}class TasksSpec implements Serializable {TasksSpec() {}def foo() {println this}def runClosure(closure) {def hydratedClosure = closure.rehydrate(this, this, this)hydratedClosure.resolveStrategy = Closure.DELEGATE_ONLYhydratedClosure() }}def tasksSpec = new TasksSpec()tasksSpec.runClosure() {foo()}{code} However, the Groovy Cps implementation seems to totally disregard the fact that we carry out a rehydrate() with the intention to execute the closure in the context of the tasksSpec object. ButiInstead the closure is executed in the context of the WorkflowScript and fails with: {code:java}Java.lang.NoSuchMethodError: No such DSL method 'foo' found among steps [archive, bat, catchError, checkout, deleteDir, dir, echo, error, fileExists, getContext, git, isUnix, library, libraryResource, load, mail, node, parallel, pwd, readFile, retry, sh, sleep, stash, step, svn, timeout, tool, unarchive, unstash, waitUntil, withContext, withEnv, wrap, writeFile, ws] or symbols [all, always, apiToken, architecture, archiveArtifacts, artifactManager, batchFile, booleanParam, buildButton, buildDiscarder, caseInsensitive, caseSensitive, choice, choiceParam, clock, cloud, command, credentials, cron, crumb, defaultView, demand, disableConcurrentBuilds, downloadSettings, downstream, dumb, envVars, file, fileParam, filePath, fingerprint, frameOptions, freeStyle, freeStyleJob, fromScm, fromSource, git, headRegexFilter, headWildcardFilter, hyperlink, hyperlinkToModels, installSource, jdk, jdkInstaller, jgit, jgitapache, jnlp, jobName, junit, lastDuration, lastFailure, lastGrantedAuthorities, lastStable, lastSuccess, legacy, legacySCM, list, local, location, logRotator, loggedInUsersCanDoAnything, masterBuild, maven, maven3Mojos, mavenErrors, mavenMojos, mavenWarnings, modernSCM, myView, nodeProperties, nonStoredPasswordParam, none, paneStatus, parameters, password, pattern, pipelineTriggers, plainText, plugin, projectNamingStrategy, proxy, queueItemAuthenticator, quietPeriod, run, runParam, schedule, scm, scmRetryCount, search, security, shell, slave, sourceRegexFilter, sourceWildcardFilter, stackTrace, standard, status, string, stringParam, swapSpace, text, textParam, tmpSpace, toolLocation, unsecured, upstream, viewsTabBar, weather, zfs, zip] or globals [currentBuild, env, params] at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:176) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1280) at groovy.lang.MetaClassImpl.invok
[JIRA] (JENKINS-49904) workflow-cps groovy engine hijacks closure.rehydrate()
Title: Message Title
Gustaf Lundh created an issue
Jenkins / JENKINS-49904
workflow-cps groovy engine hijacks closure.rehydrate()
Issue Type:
Bug
Assignee:
Unassigned
Components:
workflow-cps-plugin
Created:
2018-03-04 21:48
Environment:
workflow-cps-plugin 2.45, jenkins 2.7.3
Labels:
pipeline groovy global-lib
Priority:
Major
Reporter:
Gustaf Lundh
workflow-cps-plugin's CpsScript breaks a fundamental Groovy language feature: closure.rehydrate(). In this short snippet of pipeline code we expect the closure to run successfully (which it does in a regular GroovyShell or Jenkins script console) :
class TasksSpec implements Serializable {
TasksSpec() {
}
def foo() {
println this
}
def runClosure(closure) {
def hydratedClosure = closure.rehydrate(this, this, this)
hydratedClosure.resolveStrategy = Closure.DELEGATE_ONLY
hydratedClosure()
}
}
def tasksSpec = new TasksSpec()
tasksSpec.runClosure() {
foo()
}
However, the Groovy Cps implementation seems to totally disregard the fact that we carry out a rehydrate() with the intention to execute the closure in the context of the tasksSpec object. ButiInstead the closure is executed in the context of the WorkflowScript and fails with:
