[JIRA] (JENKINS-49946) input step cannot access environment blocks

6 views
Skip to first unread message

ak@andreas-klemp-it.de (JIRA)

unread,
Mar 6, 2018, 4:55:01 AM3/6/18
to jenkinsc...@googlegroups.com
Andreas Klemp created an issue
 
Jenkins / Bug JENKINS-49946
input step cannot access environment blocks
Issue Type: Bug Bug
Assignee: Unassigned
Components: pipeline
Created: 2018-03-06 09:54
Environment: Jenkins 2.89.4
Labels: pipeline input environment
Priority: Minor Minor
Reporter: Andreas Klemp

The input step in declarative pipeline (JENKINS-48379) cannot access the environment blocks. Thus, dynamic data (e.g. version number) cannot be used in the input dialog. Also defining options in the input and checking the result requires redundant values, because they cannot be reused.

  • Access to $JOB_NAME and ${env.JOB_NAME} is working.
  • Access to $myVar is not working. It leads to a "no such property" exception. It doesn't matter if the variable is declared in the global or stage-local environment block.
  • Access to ${env.myVar} is not working. The value is null. It doesn't matter if the variable is declared in the global or stage-local environment block.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

andrew.bayer@gmail.com (JIRA)

unread,
Mar 7, 2018, 11:23:02 AM3/7/18
to jenkinsc...@googlegroups.com
Andrew Bayer assigned an issue to Andrew Bayer
Change By: Andrew Bayer
Assignee: Andrew Bayer

andrew.bayer@gmail.com (JIRA)

unread,
Mar 7, 2018, 11:23:02 AM3/7/18
to jenkinsc...@googlegroups.com
Andrew Bayer updated an issue
Change By: Andrew Bayer
Component/s: pipeline-model-definition-plugin
Component/s: pipeline

andrew.bayer@gmail.com (JIRA)

unread,
Mar 7, 2018, 11:25:03 AM3/7/18
to jenkinsc...@googlegroups.com
Andrew Bayer commented on Bug JENKINS-49946
 
Re: input step cannot access environment blocks

Part of this another ordering issue, like JENKINS-49947: either we can have input results available when evaluating its stage's environment or the other way around, but not both. But top-level environment variables should be available to input - that's a bug. Can you provide a simple Jenkinsfile reproducing this? Thanks!

andrew.bayer@gmail.com (JIRA)

unread,
Nov 15, 2018, 12:11:02 PM11/15/18
to jenkinsc...@googlegroups.com
Andrew Bayer resolved as Won't Fix
 

As I commented above, this is a deliberate decision on ordering - we have chosen to have input process before environment for a stage, because you may want to have the environment reference something in the workspace or something submitted from input. If you need to define a single stage environment variable and reference it in that stage's input, you can wrap the stage inside a parent stage where you define the environment variable, like this:

stage("parent") {
  environment {
    FOO = "bar"
  }
  stages {
    stage("child") {
      input {
        message "Continue with ${FOO}?"
      }
      ...
    }
  }
}
Change By: Andrew Bayer
Status: Open Resolved
Resolution: Won't Fix
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mr.marcsmith@me.com (JIRA)

unread,
Dec 5, 2018, 2:32:02 PM12/5/18
to jenkinsc...@googlegroups.com
Marc Smith commented on Bug JENKINS-49946
 
Re: input step cannot access environment blocks

Hi Andrew, here is an example pipeline that does NOT work.
Please note the environment block is global so it should be available.

pipeline {
    agent any
    environment {
        SEM_VER = "1.1.0"
    }

    stages {
        stage('Approval') {
            input {
                message "✅ All Unit tests passed, Deploy ${SEM_VER}?"
                id 'Approve & Deploy Build'
            }
            steps {
                echo 'Deploying the build...'
            }
        }
    }
}

I get 

groovy.lang.MissingPropertyException: No such property: SEM_VER for class: groovy.lang.Binding
	at groovy.lang.Binding.getVariable(Binding.java:63)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:264)
	at org.kohsuke.groovy.sandbox.impl.Checker$6.call(Checker.java:288)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:292)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:268)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:29)
	at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20)
	at WorkflowScript.run(WorkflowScript:11)
	at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.call(jar:file:/var/jenkins_home/plugins/pipeline-model-definition/WEB-INF/lib/pipeline-model-definition.jar!/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy:59)
	at WorkflowScript.run(WorkflowScript:1)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:74)
	at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
	at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)
	at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
	at com.cloudbees.groovy.cps.Next.step(Next.java:83)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
	at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122)
	at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$101(SandboxContinuable.java:34)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.lambda$run0$0(SandboxContinuable.java:59)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:58)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:182)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:332)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:83)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:244)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:232)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE

 

smith.daren.j@gmail.com (JIRA)

unread,
Mar 5, 2019, 1:59:02 PM3/5/19
to jenkinsc...@googlegroups.com

I'm surprised this issue has been closed. I cannot determine a way to display any dynamic values in the input directive for declarative pipeline. I really like that this has been added, but the inability to use dynamic values in it really limits the usefulness. As other user have stated:

  1. A globally scoped environment variable results in null when used
  2. A defined groovy string that is overridden in a subsequent stage results in the originally set value
  3. The recommendation for a nested stage results in an error because only steps or parallel are allowed keyword in a stage. Changing to stages to parallel allows it to work, but still results in a null value for the env var just as the globally scoped env var did.

For now it appears we are stuck utilizing another stage without an agent to get the desired result, but that is not very clean and defeats the purpose that the declarative input directive was meant to solve.

tamerlaha@gmail.com (JIRA)

unread,
Apr 8, 2019, 1:47:02 PM4/8/19
to jenkinsc...@googlegroups.com
I P assigned an issue to I P
 
Change By: I P
Assignee: Andrew Bayer I P

tamerlaha@gmail.com (JIRA)

unread,
Apr 8, 2019, 1:47:03 PM4/8/19
to jenkinsc...@googlegroups.com
I P commented on Bug JENKINS-49946
 
Re: input step cannot access environment blocks

Could this be re-opened and addressed properly, please? 

bencom@phatbean.com (JIRA)

unread,
Apr 17, 2019, 3:28:02 PM4/17/19
to jenkinsc...@googlegroups.com

I have this problem also. Would really like to have a way to use the environment in inputs

 

erik.nummela@safe.com (JIRA)

unread,
May 15, 2019, 7:51:02 PM5/15/19
to jenkinsc...@googlegroups.com
Erik Nummela assigned an issue to Andrew Bayer
 
Change By: Erik Nummela
Assignee: ipleten Andrew Bayer

erik.nummela@safe.com (JIRA)

unread,
May 15, 2019, 7:54:02 PM5/15/19
to jenkinsc...@googlegroups.com
Change By: Erik Nummela
Resolution: Won't Fix
Status: Resolved Reopened

erik.nummela@safe.com (JIRA)

unread,
May 15, 2019, 8:02:03 PM5/15/19
to jenkinsc...@googlegroups.com
Erik Nummela commented on Bug JENKINS-49946
 
Re: input step cannot access environment blocks

This simple pipeline results in values of null where the environment variables should be

 pipeline {
    agent any
    environment {
        PROJECT = "my-project"
    }

    stages {
        stage('Approval') {
            input {
              message "Do you want to release a new version of ${env.PROJECT} to AWS (revision: ${env.GIT_COMMIT})?"
              ok "Yes, proceed"
            }
            steps {
              echo "Starting to deploy ${env.PROJECT}."
            }
        }
    }
}

Which produces the following output on approval

Do you want to release a new version of null to AWS (revision: null)?

erik.nummela@safe.com (JIRA)

unread,
May 15, 2019, 8:02:04 PM5/15/19
to jenkinsc...@googlegroups.com
Erik Nummela edited a comment on Bug JENKINS-49946
This simple pipeline results in values of *null* where the environment variables should be
{code:java}

pipeline {
    agent any
    environment {
        PROJECT = "my-project"
    }

    stages {
        stage('Approval') {
            input {
              message "Do you want to release a new version of ${env.PROJECT} to AWS (revision: ${env.GIT_COMMIT})?"
              ok "Yes, proceed"
            }
            steps {
              echo "Starting to deploy ${env.PROJECT}."
            }
        }
    }
}{code}
Which produces the following output on approval invoking the pipeline
{code:java}
Do you want to release a new version of null to AWS (revision: null)?{code}
Reply all
Reply to author
Forward
0 new messages