Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38426

Handle non-literal expressions for environment variable declarations in declarative pipeline

    XMLWordPrintable

    Details

    • Similar Issues:

      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

            Activity

            Hide
            abayer Andrew Bayer added a comment -

            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.

            Show
            abayer Andrew Bayer added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment -

            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.

            Show
            abayer Andrew Bayer added a comment - 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.
            Hide
            abayer Andrew Bayer added a comment -

            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"...

            Show
            abayer Andrew Bayer added a comment - 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" ...
            Hide
            abayer Andrew Bayer added a comment -

            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.

            Show
            abayer Andrew Bayer added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                abayer Andrew Bayer
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: