[JIRA] (JENKINS-40235) Initial run of parameterized pipeline always fails the first time

13 views
Skip to first unread message

ahunt@pindropsecurity.com (JIRA)

unread,
Dec 5, 2016, 5:49:01 PM12/5/16
to jenkinsc...@googlegroups.com
Alex Hunt created an issue
 
Jenkins / Bug JENKINS-40235
Initial run of parameterized pipeline always fails the first time
Issue Type: Bug Bug
Assignee: Kohsuke Kawaguchi
Components: github-branch-source-plugin, github-organization-folder-plugin, pipeline, workflow-cps-plugin, workflow-multibranch-plugin
Created: 2016/Dec/05 10:48 PM
Priority: Minor Minor
Reporter: Alex Hunt

The first run of a pipeline that has parameters will fail when execution reaches any reference to a parameterized variable. Subsequent runs of that pipeline will have the default value set properly and will behave normally.

I was explicitly told to open a new issue, despite there being two tickets closed that seem to be this exact problem, with one being supposedly fixed in workflow-cps-plugin version 2.19 (https://issues.jenkins-ci.org/browse/JENKINS-35698).

An example of a pipeline that will fail (copied from https://issues.jenkins-ci.org/browse/JENKINS-37330, which was closed as a duplicate of JENKINS-35698):

properties ([[
  $class: 'ParametersDefinitionProperty',
  parameterDefinitions: [[
    $class: 'StringParameterDefinition',
    name: 'dependency_revision',
    defaultValue: 'master',
    description: 'Revision of dependency project to build'
    ]]
  ]])
echo "Verifying build with dependency project version ${dependency_revision}"
groovy.lang.MissingPropertyException: No such property: dependency_revision for class: groovy.lang.Binding
	at groovy.lang.Binding.getVariable(Binding.java:62)
	at
org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:224)
	at org.kohsuke.groovy.sandbox.impl.Checker$4.call(Checker.java:241)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:238)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:23)
	at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:17)
	at WorkflowScript.run(WorkflowScript:11)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:62)
	at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
	at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:54)
	at sun.reflect.GeneratedMethodAccessor983.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:58)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:32)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:29)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:29)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:164)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:360)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:236)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:226)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	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:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

I have confirmed that this is the case when running with the following plugins, and using Github organizations as the source for our Jenkinsfiles:

ace-editor:1.1
active-directory:2.0
ant:1.4
antisamy-markup-formatter:1.5
artifactory:2.8.1
authentication-tokens:1.3
aws-credentials:1.16
aws-java-sdk:1.11.37
bouncycastle-api:2.16.0
branch-api:1.11.1
build-timeout:1.18
cloudbees-folder:5.13
cobertura:1.9.8
conditional-buildstep:1.3.5
config-file-provider:2.13
credentials:2.1.10
credentials-binding:1.10
cucumber-testresult-plugin:0.9.7
datadog:0.5.5
display-url-api:0.5
docker-commons:1.5
docker-custom-build-environment:1.6.5
docker-workflow:1.9.1
durable-task:1.12
ec2:1.36
email-ext:2.52
embeddable-build-status:1.9
envinject:1.93.1
external-monitor-job:1.6
git:3.0.1
git-client:2.1.0
github:1.24.0
github-api:1.80
github-branch-source:1.10.1
github-organization-folder:1.5
git-server:1.7
global-build-stats:1.4
gradle:1.25
handlebars:1.1.1
htmlpublisher:1.11
icon-shim:2.0.3
ivy:1.26
jackson2-api:2.7.3
javadoc:1.4
jquery-detached:1.2.1
junit:1.19
ldap:1.13
mailer:1.18
mapdb-api:1.0.9.0
matrix-auth:1.4
matrix-project:1.7.1
maven-plugin:2.14
momentjs:1.1.1
node-iterator-api:1.5
pam-auth:1.3
parallel-test-executor:1.9
parameterized-trigger:2.32
pipeline-build-step:2.4
pipeline-graph-analysis:1.2
pipeline-input-step:2.5
pipeline-milestone-step:1.2
pipeline-rest-api:2.3
pipeline-stage-step:2.2
pipeline-stage-view:2.3
plain-credentials:1.3
resource-disposer:0.3
run-condition:1.0
scm-api:1.3
script-security:1.24
slack:2.1
ssh-agent:1.13
ssh-credentials:1.12
ssh-slaves:1.11
structs:1.5
subversion:2.7.1
swarm:2.2
timestamper:1.8.7
token-macro:2.0
windows-slaves:1.2
workflow-aggregator:2.4
workflow-api:2.6
workflow-basic-steps:2.3
workflow-cps:2.23
workflow-cps-global-lib:2.5
workflow-durable-task-step:2.5
workflow-job:2.9
workflow-multibranch:2.9.2
workflow-scm-step:2.3
workflow-step-api:2.5
workflow-support:2.11
ws-cleanup:0.32
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

ahunt@pindropsecurity.com (JIRA)

unread,
Dec 5, 2016, 5:51:01 PM12/5/16
to jenkinsc...@googlegroups.com
Alex Hunt updated an issue
Change By: Alex Hunt
The first run of a pipeline that has parameters will fail when execution reaches any reference to a parameterized variable. Subsequent runs of that pipeline will have the default value set properly and will behave normally.

I was explicitly told to open a new issue, despite there being two tickets closed that seem to be this exact problem, with one being supposedly fixed in workflow-cps-plugin version 2.19 (https://issues.jenkins-ci.org/browse/JENKINS-35698).

An example of a pipeline that will fail (copied from https://issues.jenkins-ci.org/browse/JENKINS-37330, which was closed as a duplicate of JENKINS-35698):
{noformat}

properties ([[
  $class: 'ParametersDefinitionProperty',
  parameterDefinitions: [[
    $class: 'StringParameterDefinition',
    name: 'dependency_revision',
    defaultValue: 'master',
    description: 'Revision of dependency project to build'
    ]]
  ]])
echo "Verifying build with dependency project version ${dependency_revision}"
{noformat}

Will fail with an error like the following:
{noformat}
{noformat}


I have confirmed that this is the case when running with the following plugins, and using Github organizations as the source for our Jenkinsfiles:
{noformat}
{noformat}

ahunt@pindropsecurity.com (JIRA)

unread,
Dec 9, 2016, 3:13:01 PM12/9/16
to jenkinsc...@googlegroups.com

ahunt@pindropsecurity.com (JIRA)

unread,
Dec 9, 2016, 3:14:01 PM12/9/16
to jenkinsc...@googlegroups.com
Alex Hunt commented on Bug JENKINS-40235
 
Re: Initial run of parameterized pipeline always fails the first time

Updated priority to major, since that was the priority of the ones that got closed.

jglick@cloudbees.com (JIRA)

unread,
Dec 16, 2016, 12:02:02 PM12/16/16
to jenkinsc...@googlegroups.com
Jesse Glick resolved as Not A Defect
 

Check the release notes and use params.dependency_revision.

Change By: Jesse Glick
Status: Open Resolved
Assignee: Kohsuke Kawaguchi Jesse Glick
Resolution: Not A Defect

jrs.dmz.2016@gmail.com (JIRA)

unread,
Jan 10, 2017, 9:26:01 PM1/10/17
to jenkinsc...@googlegroups.com
Joseph Schneider commented on Bug JENKINS-40235
 
Re: Initial run of parameterized pipeline always fails the first time

Jesse Glick I am having this exact same issue. Using 'params.variable_name' does NOT work:
`groovy.lang.MissingPropertyException: No such property: params for class: groovy.lang.Binding`

Referencing the variables as is DOES work though, starting on the second build. See https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md#build-parameters for the documentation regarding referencing build variables.

I am running Jenkins ver. 2.19.1, and tried to find the release notes you mentioned, but I don't see anything pertinent in the last month (looking here: https://jenkins.io/changelog/). Can you please ropen this issue?

jrs.dmz.2016@gmail.com (JIRA)

unread,
Jan 10, 2017, 9:28:01 PM1/10/17
to jenkinsc...@googlegroups.com
Joseph Schneider reopened an issue
 
Change By: Joseph Schneider
Resolution: Not A Defect
Status: Resolved Reopened

ahunt@pindropsecurity.com (JIRA)

unread,
Jan 11, 2017, 11:00:02 AM1/11/17
to jenkinsc...@googlegroups.com
Alex Hunt commented on Bug JENKINS-40235
 
Re: Initial run of parameterized pipeline always fails the first time

Joseph Schneider What version of the workflow-cps plugin are you running? Jesse's solution worked for us, but wasn't well explained causing the reopening of multiple tickets like this one.

You need to have workflow-cps plugin at least version 2.19. The version of Jenkins doesn't matter, AFAIK. You also need to reference your variables as params.variable_name for them to work on the first run.

jrs.dmz.2016@gmail.com (JIRA)

unread,
Jan 11, 2017, 1:11:02 PM1/11/17
to jenkinsc...@googlegroups.com

Thanks! My current version of workflow-cps (aka Pipeline Groovy Plugin for those reading at home) is 2.15. Will update and confirm/deny if it works.

jglick@cloudbees.com (JIRA)

unread,
Jan 12, 2017, 11:53:01 AM1/12/17
to jenkinsc...@googlegroups.com
Jesse Glick resolved as Not A Defect
Change By: Jesse Glick
Status: Reopened Resolved
Resolution: Not A Defect

arpan.ps@gmail.com (JIRA)

unread,
Mar 9, 2017, 7:17:01 AM3/9/17
to jenkinsc...@googlegroups.com
Arpan Khandelwal commented on Bug JENKINS-40235
 
Re: Initial run of parameterized pipeline always fails the first time

I am facing same issue.  workflow-cps version is 2.29. it works fine otherwise. Please let me know if you need more info.

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

arpan.ps@gmail.com (JIRA)

unread,
Mar 9, 2017, 7:18:01 AM3/9/17
to jenkinsc...@googlegroups.com
Arpan Khandelwal edited a comment on Bug JENKINS-40235
I am facing same issue.  workflow-cps version is [2.29|http://updates.jenkins-ci.org/latest/workflow-cps.hpi]. it works fine otherwise. Please let me know if you need more info. Also it fails when we create new branch while using mulitbranch plugin.

t.honacker@gmail.com (JIRA)

unread,
Mar 22, 2017, 4:34:02 AM3/22/17
to jenkinsc...@googlegroups.com

Arpan Khandelwal Same here, using version 2.29 of workflow-cps we can't access params.variables anymore

scm_issue_link@java.net (JIRA)

unread,
Mar 24, 2017, 8:54:05 AM3/24/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Gabriel Le Breton
Path:
TUTORIAL.md
http://jenkins-ci.org/commit/pipeline-plugin/bd8d95b303b9e20d530b247d478261e76585feaf
Log:
Build parameters not groovy variables anymore

I had an issue when working with Build parameters, found the solution in JENKINS-40235 and added details here: http://stackoverflow.com/a/41276956/1092815

Reply all
Reply to author
Forward
0 new messages