[JIRA] (JENKINS-38426) Handle non-literal expressions for environment variable declarations in declarative pipeline

5 views
Skip to first unread message

andrew.bayer@gmail.com (JIRA)

unread,
Sep 21, 2016, 12:29:03 PM9/21/16
to jenkinsc...@googlegroups.com
Andrew Bayer created an issue
 
Jenkins / Improvement JENKINS-38426
Handle non-literal expressions for environment variable declarations in declarative pipeline
Issue Type: Improvement Improvement
Assignee: Andrew Bayer
Components: pipeline-model-definition-plugin
Created: 2016/Sep/21 4:28 PM
Priority: Minor Minor
Reporter: Andrew Bayer

Should you try anything like: 

environment {
  FOO = blah()
  BAZ = "${blah()}"
}

you will be rewarded with a stacktrace and a sandbox violation. 

org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject invokeMethod java.lang.String java.lang.Object (org.jenkinsci.plugins.workflow.cps.CpsClosure2 foo)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:181)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:117)
	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:21)
	at org.jenkinsci.plugin

Need to figure out what can be allowed here and what can't - i.e., steps are potentially problematic since we're definitely not in a node context when setting up the environment, and we also need to understand how we're evaluating the environment values in the first place. So yeah, more thought needed.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

andrew.bayer@gmail.com (JIRA)

unread,
Sep 22, 2016, 2:07:03 PM9/22/16
to jenkinsc...@googlegroups.com
Andrew Bayer started work on Improvement JENKINS-38426
 
Change By: Andrew Bayer
Status: Open In Progress

andrew.bayer@gmail.com (JIRA)

unread,
Sep 22, 2016, 2:54:01 PM9/22/16
to jenkinsc...@googlegroups.com
Andrew Bayer commented on Improvement JENKINS-38426
 
Re: Handle non-literal expressions for environment variable declarations in declarative pipeline

So the origin of this pain is the FOO = "BAR" style for environment variables - when trying to resolve the closure, Groovy is trying to resolve the right-hand side whether I like it or not. Trying to find a way around that.

andrew.bayer@gmail.com (JIRA)

unread,
Sep 22, 2016, 3:32:02 PM9/22/16
to jenkinsc...@googlegroups.com
Change By: Andrew Bayer
Status: In Progress Review

andrew.bayer@gmail.com (JIRA)

unread,
Sep 22, 2016, 3:33:01 PM9/22/16
to jenkinsc...@googlegroups.com
 
Re: Handle non-literal expressions for environment variable declarations in declarative pipeline

A tentative solution is up for review at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/20. This did require mandating that non-literal environment variable values be single-quoted in the Jenkinsfile so that we can control how/when they're actually evaluated. No change is needed on the JSON side.

andrew.bayer@gmail.com (JIRA)

unread,
Sep 22, 2016, 6:41:04 PM9/22/16
to jenkinsc...@googlegroups.com

fwiw, if we switched to this syntax:

environment {
  FOO "BAR"
}

Then it would work...though I feel like I had problems with all caps method names, so it might need to be "FOO" "BAR"...

andrew.bayer@gmail.com (JIRA)

unread,
Sep 23, 2016, 12:54:01 PM9/23/16
to jenkinsc...@googlegroups.com

With https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/22, I seem to have gotten almost everything we want - not using an env var defined in the same block inside a subsequent env var, but everything else. So...that's the PR to look at now.

scm_issue_link@java.net (JIRA)

unread,
Sep 29, 2016, 10:40:01 AM9/29/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:
src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/model/MethodMissingWrapperWhitelist.java
src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy
src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/EnvironmentTest.java
src/test/resources/nonLiteralEnvironment.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/7f05b70a3318835469d2708e7f0d0aadeb8afeb4
Log:
[FIXED JENKINS-38426] Allow non-literal expressions in env vars.

Allowing fall-through delegation and whitelisting getProperty(s) on
ClosureModelTranslator and PropertiesToMapTranslator lets us do env
vars with values like:

  • "$ {currentBuild.getNumber()}

    "

  • currentBuild.getNumber()

Can't do "$

{PREVIOUSLY_DEFINED_ENV}

_something" yet, though. Still
trying to figure that one out.

andrew.bayer@gmail.com (JIRA)

unread,
Oct 10, 2016, 7:42:01 AM10/10/16
to jenkinsc...@googlegroups.com
Change By: Andrew Bayer
Status: In Review Resolved
Resolution: Fixed

bitwiseman@gmail.com (JIRA)

unread,
Oct 22, 2019, 11:25:44 PM10/22/19
to jenkinsc...@googlegroups.com
Liam Newman closed an issue as Fixed
 

Bulk closing resolved issues.

Change By: Liam Newman
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages