I just now tested this back to Jenkins 1.518 and it has the same behavior. Again, I thought I had verified this works previously (2 builds of the same project in the queue at the same time), but now I am not 100% confident. I'll need to create a new instance of Jenkins to test this out and try going back to a much older (for me) release.

I just attempted to start multiple instance of the same build, all with unique parameters and it was a mess.

Here is what I see:

1. Sometimes it created a new unique job
2. Sometimes it "merged" with the next job in the queue, replacing the parameters

In my testing I used the following parameters:

1. Branch (drop down list box of the available branches)
2. Build type (choice between -D and -R)
3. Check box for Test build (is this a test build?)

I tried different combinations of each of these and could not get consistent behavior.

We're just getting ready to roll out Jenkins and this kind of bug is really throwing off the plan to roll out. Hope to see it fixed soon, or someone can educate me on what I'm not doing right.

Thanks!

OK, I think I've isolated the root of this issue. It appears that the plugin is not honoring unique values for "List Subversion Tags" type parameter. So, if the only parameter value that is different between two build executions is the Tag or Branch selected by the user, Jenkins will combine the two and use the branch or tag selected by the second build request.

To help my team get around this for now, I've added a new parameter requesting the user type in their name. This will keep Jim from clobbering Suzy etc. It won't keep Jim from clobbering Jim's other branch build though.

Shannon Kerr, good job on isolating this. I'm also waiting for a fix, but I didn't know how to reproduce the problem (tried with string parameters, but they worked fine).

As for workarounds, I think BUILD_NUMBER could be passed to a downstream job as a parameter by using "Predefined parameters" in "Trigger parameterized build on other projects" step - that should solve the problem with merged downstream jobs.

Thank you for the suggestion Andrejs. Unfortunately I'm not having this issue with connected jobs. These jobs using the "List Subversion Tags" type parameter are stand-alone. We need this fix. If my Java was better, I'd look into the code myself. I hope we can see some action on this as it is a legitimate bug.

We have the same problem with Jenkins 1.522

Can anything be done about this issue? I have to have developers enter some unique test to prevent their jobs from being combined. I'd really like to hear about a fix for this.

Really this is a killer. I have to put in a field just to let the user put in unique text to prevent the jobs from combining. Can't this be fixed?

Workaround: Random String Parameter plugin

Wow, this is stupid. ListSubversionTagsParameterValue does not override equals() and hashCode(), resulting in the default implementation being used that only compares the parameter name and type.

Random string parameter plugin did not fix the issue for me. I did try that previously.

Thanks for taking my poor layman's explanation and isolating it more meaningfully.

As I pointed out, random string parameter did not work either. Someone may want to look into that too.

Any idea when this might be fixed Daniel?

Whenever someone merges my PR (linked above) and cuts a release. It's been a year since one of the usual maintainers actually worked on the plugin (except releases and merging pull requests): Everything else was pull requests + the Cloudbees guys, so I don't expect it to happen anytime soon. If you know the basics of Git and Maven, my suggestion is to create a Subversion plugin build based on 2.3 (2.4 is too broken IMO) with this change.

Code changed in jenkins
User: Daniel Beck
Path:
src/main/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterValue.java
http://jenkins-ci.org/commit/subversion-plugin/2dec2d0978ea2e309fe962be786a6c4ec92417b8
Log:
[FIXED JENKINS-18534] equals()/hashCode() for parameter value

The default implementation considers parameters with the same name
to be identical, resulting in queue items being collapsed.

With this change, different values for a parameter will result in
different builds.

Code changed in jenkins
User: Daniel Beck
Path:
src/test/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterValueTest.java
http://jenkins-ci.org/commit/subversion-plugin/8a96c32606fe8f49d10155a50883862edb931baa
Log:
JENKINS-18534 Added test contributed by @christ66

Code changed in jenkins
User: Oleg Nenashev
Path:
src/main/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterValue.java
src/test/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterValueTest.java
http://jenkins-ci.org/commit/subversion-plugin/7fecc427c206d866b13d02568bbc57eec9b95126
Log:
Merge pull request #87 from daniel-beck/JENKINS-18534

[FIXED JENKINS-18534] equals()/hashCode() for parameter value

Compare: https://github.com/jenkinsci/subversion-plugin/compare/2a16745d63a1...7fecc427c206

Code changed in jenkins
User: Daniel Beck
Path:
src/main/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterValue.java
http://jenkins-ci.org/commit/subversion-plugin/82932212bcfd9a2051e91ac2cb2ae2531b5264d9
Log:
[FIXED JENKINS-18534] equals()/hashCode() for parameter value

The default implementation considers parameters with the same name
to be identical, resulting in queue items being collapsed.

With this change, different values for a parameter will result in
different builds.

(cherry picked from commit 2dec2d0978ea2e309fe962be786a6c4ec92417b8)

Code changed in jenkins
User: Daniel Beck
Path:
src/test/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterValueTest.java
http://jenkins-ci.org/commit/subversion-plugin/0dc322ba5f8a87131588f6174719fe6cb5d73cdc
Log:
JENKINS-18534 Added test contributed by @christ66

(cherry picked from commit 8a96c32606fe8f49d10155a50883862edb931baa)