Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Fix
Description
In a pipeline stage, it is not possible to reference a variable that is set inside a shell script as part of a former stage, see the simplified example below. In my use case, the first stage reads a file in the workspace and evaluates part of its content to set the variable.
stage 'Fetch version'
sh '''#!/bin/sh
version=abc'''
stage 'Second'
sh "${mvnHome}/bin/mvn -f all/pom.xml -Dversion=$version ...
Result:
groovy.lang.MissingPropertyException: No such property: version for class: WorkflowScript
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:458)
at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.getProperty(DefaultInvoker.java:25)
at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:17)
at WorkflowScript.run(WorkflowScript:48)
I've tried a lot of different things setting and accessing the variable, including the environment variable env, but nothing worked.
Attachments
Activity
sh requires a workspace to run to begin with, I guess you just omitted it for clarity. Moreover, in your example $version is being resolved by the Groovy engine, that's why you are getting groovy.lang.MissingPropertyException on version. Just replace " (double quotes) with ' (single quote) around the shell line to let shell to look up for that environment variable.
And finally, each sh step has its own non-shared scope, so as a general rule: use plain groovy variables to pass information from one step to another (for example using readFile as danielbeck pointed out to load something written to disk by the shell step into a groovy variable which you can pass later to the second shell step).
Hi amuniz,
thanks for the feedback.
Yes, sure, the issue here is how to access a variable from a former stage, not how to define a stage for checking out sources from version control.
For me, as a user, a variable is resolved, if Jenkins replaces the variable with the content during build time. The variable could not be resolved and that's what the error message says? I've applied the different syntax before, and it also did not work. I've also tried this and that, and the ticket description just reflects a current situation, where I did not know the recommended, official way, and I'm very thankful for your hint into this direction.
Yes, the different scopes. I know. This is really a long term pain. 
Actually, as part of a Pipeline, passing a variable to a later build stage by using a file to read+restore the variable can only be a workaround.
Thank you.
Use the `readFile` workflow function: https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-readfile-code-read-file-from-workspace
I'm pretty sure the behavior necessary to make the script you're demonstrating work (either as pipeline variable, or shell variable) could have unexpected and impossible to debug side effects if implemented.