Details
-
Improvement
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
Description
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.
Attachments
Issue Links
- is duplicated by
-
JENKINS-37777 Pipeline Config: Unable to assign any non literal to an environment variable
-
- Closed
-
- links to
Activity
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.
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"...
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.
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.
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.