Confirmed that reverting to 2.15 fixes the problem.

For anyone else hitting this, download the source from here:
https://github.com/jenkinsci/promoted-builds-plugin/archive/promoted-builds-2.15.tar.gz
unpack, mvn clean package, then copy promoted-builds-plugin-promoted-builds-2.15/target/promoted-builds.hpi to JENKINS_ROOT/plugins.promoted-builds.jpi
note the extension change.

or, instead of building...
http://updates.jenkins-ci.org/download/plugins/promoted-builds/2.15/promoted-builds.hpi

https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Byhand

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/hudson/matrix/FilterScript.java
http://jenkins-ci.org/commit/matrix-project-plugin/a40e83f731884c05fc15af13786d4306aec127a0
Log:
Merge pull request #1 from mc1arke/JENKINS-22679

[FIXED JENKINS-22879] Fix Groovy classloading issue.

Compare: https://github.com/jenkinsci/matrix-project-plugin/compare/51ac5ab4ef3a...a40e83f73188

Problem still exists in jenkins update site.

What's needed to get the above merge pull into the global plugin update site?

This seems to be caused by the fix for JENKINS-22005. Reverting to 2.16 fixes the problem. I can reproduce the issue using the following steps:

1) Create a job job1 with a string parameter named param1.
2) Create a job job2 with a string parameter named param1.
3) Create a job job3 with a string parameter named param1.
4) Add a promotion process promotion1 to job3 with criteria 'Only when manually approved'. Add an action 'Trigger parameterized build on other projects' to the promotion which triggers job1 with predefined parameters 'param1=${param1}'.
5) Add a promotion process promotion2 to job3 with criteria 'When the following downstream projects build successfully' on downstream project job1. Add an action 'Trigger parameterized build on other projects' to the promotion which triggers job2 with predefined parameters 'param1=${param1}'.
6) Run job3 with param1=someString.
7) Manually approve promotion1. You will see that job1 is correctly run with param1=someString.
8) Promotion process promotion2 will now automatically start job2. But job2 will be run with param1=${param1} which is not correct.

Hello.

I just updated to the 2.18 SNAPSHOT that was posted a few days back to fix the re-execute button. I have now run into this issue. Will this get fixed for 2.18?

Confirmed reverting to 2.16 fixes the problem for me.

Hi, I've prepared a pull request with a fix for the issue described. I would kindly appreciate any committer picking it up

https://github.com/jenkinsci/promoted-builds-plugin/pull/50

+1 for the pull request.

The above pull request is closed, is this issue fixed?
There's no indication from the change logs that this was addressed.

This bug still exists in 2.20.

Build parameters are no longer expanded. My promotion directory looks like this after any version past 2.15:

drwxr-xr-x 3 jenkins nogroup 4096 Apr 1 12:39 ${PROJECT}

instead of

drwxr-xr-x 3 jenkins nogroup 4096 Apr 1 12:39 Sling-Controller

Where PROJECT=Sling-Controller as defined as a build-parameter in the job.

Here's some more info form a promotion log:

build BapSshPromotionPublisherPlugin[delegate=BapSshPublisherPlugin[consolePrefix=SSH: ,delegate=BPInstanceConfig[publishers=[BapSshPublisher[configName=boot-1.qa,verbose=false,transfers=[BapSshTransfer[sourceFiles=*,excludes=,removePrefix=,remoteDirectory=${PROJECT}/${BRANCH}/QA/${BUILD_NUMBER},remoteDirectorySDF=false,flatten=false,cleanRemote=false,noDefaultExcludes=false,makeEmptyDirs=false,patternSeparator=[, ]+,execCommand=,execTimeout=120000,pseudoTty=false]],useWorkspaceInPromotion=false,usePromotionTimestamp=false,retry=<null>,label=<null>,credentials=<null>]],continueOnError=false,failOnError=false,masterNodeName=<null>,alwaysPublishFromMaster=false,paramPublish=<null>]]] SUCCES

note the "remoteDirectory=${PROJECT}/${BRANCH}/QA/${BUILD_NUMBER},"

Yep, it's waiting there for almost half a year now. It's pretty frustrating that it still hasn't been merged.

Getting hit by this (I believe), cannot take EnvInject values in my promotion step

Code changed in jenkins
User: Wilco Greven
Path:
src/main/java/hudson/plugins/promoted_builds/Promotion.java
src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java
src/test/java/hudson/plugins/promoted_builds/conditions/SelfPromotionTest.java
http://jenkins-ci.org/commit/promoted-builds-plugin/80156830fe9a6da762bb6269b79c3f3b12dbede8
Log:
JENKINS-22679
Don't skip passing the target build parameters to the promotion build when the promotion build doesn't have its own parameters.

Code changed in jenkins
User: Steven Christou
Path:
src/main/java/hudson/plugins/promoted_builds/Promotion.java
src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java
src/test/java/hudson/plugins/promoted_builds/conditions/SelfPromotionTest.java
http://jenkins-ci.org/commit/promoted-builds-plugin/34157a212e757c4306fdd7be4db855f1b3351e3a
Log:
Merge pull request #49 from wgreven/JENKINS-22679

JENKINS-22679 Pass the target build parameters to the promotion build when the promotion build doesn't have its own parameters.

Compare: https://github.com/jenkinsci/promoted-builds-plugin/compare/726f7a0966f5...34157a212e75

Still broken in 2.21 release.

Was pull request #49 from wgreven/JENKINS-22679 not merged?

Snippet from promotion log using 2.21 shows:
+ relpath=releases///QA/172

reverting back to 2.15:
+ relpath=releases/Collections/develop/QA/172

Note the lack of the "Collections" and "develop" strings in the 2.21 case.
These are env-inject plugin variables.

Still broken with env-inject vars and 2.22 version.

PR #49
vStone said: "This does not seem to fix variables that were inserted with envinject"
wgreven-ibr respond: "No, it's a fix specific for the build parameters."

Seems that the problem for this Issue is solved, Should we open a new BUG specific for env-inject?

Filed JENKINS-30772 for env-inject plugin. with reference to this bug.

Sorry, over last months I had no time to work on the plugin, because I had to focus on the Jenkins core and other projects. I also have not been using this plugin on my own since 2016. So I have decided to unassign the issues so that there is no expectation that I work on them anytime soon.

Currently the plugin is being transfered to another maintainer. Hopefully he will have some time to finish triaging of the issues and maybe to deliver some fixes. But, as in any community-driven project, everybody is welcome to propose pull requests and to contribute to the plugin's state.