Jenkins 1.651.2: Parameterized Trigger Plugin Not Passing Parameters To Downstream Job

[Mark Bretl]

Hi All,

I have run into an issue with the Parameterized Trigger Plugin after upgrading to the latest LTS build 1.651.2, where the triggered parameters (using Predefined) are not being passed to the downstream job. I read the security notes and found that SECURITY-170 could be affecting my issue. I decided on doing the workaround of adding -Dhudson.model.ParametersAction.keepUndefinedParameters=true and now the parameters are being passed again.

I see that there is an issue open, https://issues.jenkins-ci.org/browse/JENKINS-34814, however, it is against another plugin. Should I create a new JIRA issue for the parameterized trigger plugin?

[Mark Waite]

I don't know that another JIRA issue is the solution.  I found that passing parameters downstream works (at least for me) if the downstream job has a parameter named which matches the parameter being passed from the upstream job.  Could you try the same thing in your case to see if it resolves it for you as well?

My upstream job was passing the parameter, then my downstream job was reading it as an environment variable, rather than as a job parameter.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b253b369-f730-4221-a9b5-ff8d9a02c6ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Bretl]

Hi Mark,

In my job, my upstream job was passing downstream the following using the predefined parameter:

BUILD_NUM=1605.132

In the downstream job I use the parameter as a build_name, as well as an environment variable. The first issue is that when trying to set the build name using the BUILD_NUM property, I get the following:

Set build name.
Unrecognized macro 'BUILD_NUM' in '${BUILD_NUM}'

Second issue is in a shell, when trying to use it as an environemnt variable I get:
+ echo "BUILD_NUM = $BUILD_NUM"
BUILD_NUM = $BUILD_NUM

I would think others are in my situation as well. I took a look at the source on GitHub and it doesn't seem like the plugin is sending them as 'safeParameters' as the security notice states and no updates/releases to the plugin have been done since Dec 2015. On the page SECURITY-170, it states 'only build parameters that have been explicitly defined in a job's configuration will be available', so the plugin needs to mark them as 'safe' to have them passed to the downstream job as far as I can tell.

Am I reading the security notice correctly?

Thanks,

Mark B.

[Mark Waite]

Are you sure that the downstream job is defined to have an explicit parameter named "BUILD_NUM"?  In my case, I was relying on the upstream job to inject the variable from the upstream job into the downstream job, even though the downstream job did not declare that it accepted that parameter.

When I changed the downstream job to explicitly accept the parameter, then it worked as expected.

Mark Waite 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/61a7524b-27d0-4609-aac8-bac9ef994626%40googlegroups.com.

[Mark Bretl]

Mark,

I think I am with you that I was relying on the upstream job to inject the variable, however, I am not following on how to 'define an explicit parameter'. 

Do I need to add the properties to 'Inject environment variables to the build process' or another setting?

Thanks again,

--Mark

[Arnaud Héritier]

Hi Mark,

  Yes I think that a dedicated issue should be created and listed here : https://wiki.jenkins-ci.org/display/JENKINS/Plugins+affected+by+fix+for+SECURITY-170

  We need to fix all these plugins

BR

--

You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b253b369-f730-4221-a9b5-ff8d9a02c6ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Mark Waite]

I should have been more clear about the technique I used.

In my case, the downstream job was not a parameterized job, so it did not declare that it took any parameters, but it relied on the upstream job to pass those parameters to the downstream job.

I changed the downstream job to make it a parameterized job, with a parameter whose name matched the parameter being passed to it by the upstream job.

I think the concept was that the job was previously implicitly paramterized because it relied on the upstream job to define and pass the parameter and its value.  Now, the job is explicitly parameterized because anyone who starts the job must provide a value for that parameter.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/1b1fc3c9-d3da-466b-a46d-b0138e8bebe3%40googlegroups.com.