Using .with on a WorkflowScript in a Jenkins pipeline - jenkins

Question

I have some common parts of my Jenkins pipeline scripts extracted to helper classes in a pipeline library. For example, every job should use timestamps and ansiColor so let's write this:
class Foo implements Serializable {
WorkflowScript wfs
Foo(WorkflowScript wfs) {
this.wfs = wfs
}
def foo(Closure body) {
this.wfs.timestamps {
this.wfs.ansiColor {
body()
}
}
}
}
The pipelines can use this class like this:
def f = new Foo(this)
f.foo { echo "Hello World!" }
This works, but prefixing each pipeline step with this.wfs in the helper class adds a lot of noise. I was considering writing this instead:
class Foo implements Serializable {
WorkflowScript wfs
Foo(WorkflowScript wfs) {
this.wfs = wfs
}
def foo(Closure body) {
this.wfs.with {
timestamps {
ansiColor {
body()
}
}
}
}
}
This way however the job fails with the following error:
hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: Foo.timestamps() is applicable for argument types: (org.jenkinsci.plugins.workflow.cps.CpsClosure2) values: [org.jenkinsci.plugins.workflow.cps.CpsClosure2#279d65ed]
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:58)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:64)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:160)
at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:157)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:142)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:158)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:162)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
at Foo.foo(WorkflowScript:146)
at com.cloudbees.groovy.cps.CpsDefaultGroovyMethods.with(CpsDefaultGroovyMethods:242)
at Foo.foo(WorkflowScript:145)
at WorkflowScript.run(WorkflowScript:159)
at ___cps.transform___(Native Method)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:84)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:113)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:83)
at sun.reflect.GeneratedMethodAccessor188.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46)
at com.cloudbees.groovy.cps.Next.step(Next.java:83)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:186)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:370)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:93)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:282)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:270)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:66)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
What's wrong with using .with on a WorkflowScript? With other classes this seems to work just fine. Is there a workaround?

Answer 1

If all you wish to do is to wrap a pipeline you can achieve that in a shared library step. Suppose you create Foo.groovy:
def call(Closure body) {
pipeline {
agent any
stages {
stage("Initialize") {
steps {
timestamps {
ansiColor {
echo "Hello world!"
body()
}
}
}
}
}
}
}
Then you can use Foo instead of pipeline:
library "your-shared-lib"
Foo {
echo "123"
}
This example is limited to one stage, however if you want more stages you'll have to use scripted pipeline. In Foo.groovy you'll need to put body() inside a script block and then you can add whatever you want:
library "your-shared-lib"
Foo {
stage("1") {
echo "Only scripted pipeline here"
}
stage("2") {
// If you plan on using more than one node it's better to
// change the agent in Foo.groovy to none
node("label") {
}
}
}
The disadvantages to this method are that you're forced to use scripted pipeline, and all your stages will be nested inside the parent stage of Foo (but Blue Ocean is smart enough to display the stages as following to the parent stage.)