IMO, this use case really needs to be specifically spelled out on the plugin\'s webpage/documentation.
Let\'s say I have a project named U for upstream and D for d
Turns out, like the test case says, this was all I had to do. I tested this by committing to U, then committed again while it was building. Once D started building, it grabbed the first commit, not the latest. That's how I tested it was working.
Better feedback would be appreciated, but at least I know it's working.
I don't know why "Subversion revision" parameter does not work (see troubleshooting hint below), but try adding the parameter manually under "Trigger parameterized build on other projects" with "Add parameter" dropdown. Simplest might be to add "Current build parameters".
You can also just specify the parameters you want, with the values you want with "Predefined parameters", probably like this:
SVN_REVISION=${SVN_REVISION}
Marking D as parameterized shouldn't be necessary, that just means you can specify parameters with default values, and make Jenkins ask for the parameters when build is triggered manually. But anything that schedules a new build (like Parameterized trigger plugin does) can always add any parameters to that build, no matter how the job is configured.
Troubleshooting hint: add a build step to dump environment variables (which should have all the build parameters too) in the triggered build. Simplest is to add "Execute shell"/"Execute Windows batch command" with command to dump environment (export
with unix shell, set
with Windows).
Then from build console output, see if the parameters are as they should be (exist and have right values).