-
Improvement
-
Resolution: Fixed
-
Minor
I noticed that job input parameters are not available inside of the sh task
for example:
sh 'echo ${ARTIFACTS}'
I'm aware of that I can interpolate the variable but I have scripts which expects to have variables set.
// expects to have ARTIFACTS env available sh('./some-python-script.py'))
Migration from my old hand patched pipeline to the new workflow would be easier if Job parameters and injected environment variables are available like in the regular script step (freestyle project)
- is blocking
-
JENKINS-28447 CpsScmFlowDefinition does not resolve variables
-
- Resolved
-
- is related to
-
JENKINS-29952 Allow access to environment variables as Groovy variables
-
- Resolved
-
- links to
[JENKINS-30910] Job parameters should be exposed as environment variables
Cameron I
added a comment - Also related to JENKINS-36528 ? 
Anna Kordas
added a comment - Does anyone found some workaround? anna_kkk You can just use double quotas instead:
sh "echo ${ARTIFACTS}"
If you need this variable to be passed to the script as environment variable:
sh "export ARTIFACTS=${ARTIFACTS} && <your-script-name>"
Mike Scherbakov
added a comment - - edited anna_kkk You can just use double quotas instead:
sh "echo ${ARTIFACTS}"
If you need this variable to be passed to the script as environment variable:
sh "export ARTIFACTS=${ARTIFACTS} && <your-script-name>" abayer We will probably need this for declarative pipeline because you cannot assign variables inside pipeline block without script.
I ran into this trying to use an input step. If the values returned from the user input are available in env automatically they can be used throughout the pipeline.
my workaround was:
script
{ env.ENVIRONMENT = input message: 'Deploy Application?', ok: 'Go! Go! Go!', parameters: [choice(choices: 'Development\nStaging\nProduction', description: 'Pick Environment to Deploy.', name: 'ENVIRONMENT')] }hrmpw So I think input step return values are a different thing than ParameterValue...
jglick Why don't we have an equivalent to this in WorkflowRun? If we did, we'd pick up ParameterAction contributions automatically...
Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java
src/test/java/org/jenkinsci/plugins/workflow/job/WorkflowRunTest.java
http://jenkins-ci.org/commit/workflow-job-plugin/219fde38743eccc3c91cdd32f3061645583d8314
Log:
[FIXED JENKINS-30910] Build environment should include parameters.
Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/test/java/org/jenkinsci/plugins/workflow/cps/CpsScmFlowDefinitionTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/86c7ea988f371a8b50d2a2ed41ad2fcb4cd6de25
Log:
[FIXED JENKINS-28447] CpsScmFlowDefinition does not resolve variables.
Actual fix is implied by JENKINS-30910; this is just the integration test.
Wim Ederveen
added a comment - With the fix in job plugin 2.7 we are able to start a pipeline build while using the choice parameter
Wim Ederveen
added a comment - With the fix in job plugin 2.7 we are able to start a pipeline build while using the choice parameter 
Possible in conjunction with
JENKINS-29952andJENKINS-27295, I think: the current flattened parameters could be moved to environment variables, which would like all other env vars be accessible via Groovy as now, and there would be a separate pseudovariable which would give access to typed objects and more.