-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.19.1; pipeline-utility-steps 1.2.1
`readYaml` appears to require a workspace, even if only the `text` argument is used.
Using this pipeline script:
echo readYaml(text: "---")
I get this result:
Started by user Mike Dougherty [Pipeline] readYaml Required context class hudson.FilePath is missing Perhaps you forgot to surround the code with a step that provides this, such as: node [Pipeline] End of Pipeline org.jenkinsci.plugins.workflow.steps.MissingContextVariableException: Required context class hudson.FilePath is missing at org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:253) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:179) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:126) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source) 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:151) at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:21) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:115) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:103) at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149) at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16) at WorkflowScript.run(WorkflowScript:1) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82) at sun.reflect.GeneratedMethodAccessor434.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.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55) at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45) at sun.reflect.GeneratedMethodAccessor447.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.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:58) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30) at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:163) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:324) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:78) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:236) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:224) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:63) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) 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:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Finished: FAILURE
Adding a `node` block works as expected:
node {
echo readYaml(text: "---")
}
Started by user Mike Dougherty
[Pipeline] node
Running on CentOS71 (devicemapper) (selinux-enabled) (i-a80a993d) in /home/ec2-user/workspace/pipeline-test
[Pipeline] {
[Pipeline] readYaml
[Pipeline] echo
null
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
[JENKINS-40167] readYaml and readJSON require a workspace even if the workspace is not needed
christophetd
added a comment - aarondmarasco_vsi did you find any way to fix this? 
Aaron D. Marasco
added a comment - christophetd Nope, sorry. I put it in a node. This also applies to readProperties. I'm using the text parameter to pass in the result of calling libraryResource, so there shouldn't be any need for a workspace at this point (or, indeed, at any point in ths job in question, since it's being used to orchestrate other jobs). Wrapping the call in a node block makes it work.
Marcin Grinberg
added a comment - Paul I've just found the same behavior with readProperties.
It makes more sense when you want to read a file. But it could look at master's workspace if it isn't called in the node scope. Wouldn't that be a good solution in case you want to do something outside a node?
Marcin Grinberg
added a comment - Paul I've just found the same behavior with readProperties.
It makes more sense when you want to read a file. But it could look at master's workspace if it isn't called in the node scope. Wouldn't that be a good solution in case you want to do something outside a node? Looks like this was fixed in pipeline-utility-steps 1.4.1: https://github.com/jenkinsci/pipeline-utility-steps-plugin/pull/31
This issue should be able to be closed AFAICT.
Aaron D. Marasco
added a comment - I was able to confirm readJSON worked outside of a node block using pipeline-utility-steps 2.2.0. Thanks for the heads-up mletterle. One less Jenkins bug number in my groovy code.
Aaron D. Marasco
added a comment - I was able to confirm readJSON worked outside of a node block using pipeline-utility-steps 2.2.0. Thanks for the heads-up mletterle . One less Jenkins bug number in my groovy code. Also the `readYaml` is working now with 2.2.0. Thanks for letting us know!
Not surprisingly, this affects readJSON as well.