-
Bug
-
Resolution: Fixed
-
Major
Different values selected for 'List Subversion Tags' parameters are not considered in determining parameter equality.
ListSubversionTagsParameterValue needs to implement hashCode() and equals() properly.
- links to
[JENKINS-18534] Jobs from same project are combined when different branches selected for each job
| Summary | Original: Cannot add new build to queue from same project using different parameters | New: Cannot add new build to queue from same project with different parameters |
| Component/s | New: parameterized-trigger [ 15592 ] | |
| Component/s | Original: parameters [ 15594 ] |
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!
| Description |
Original:
I start a parameterized build from project A via the build button. A second parameterized build from the same project was then started via the build button, but with different parameter values. Instead of having two jobs in the queue, the second job is not added and instead takes over the first job in the queue. If the jobs were started by different users, both users names show up as the "Started by" users. Only the second user's parameters are used and retained. The first user's job is just lost. I'm going to see if this ever worked, but I'm pretty sure it did. I'm still pretty new to Jenkins, but I thought I had tested this out before and had seen two instances of the same job sitting in the queue. |
New:
(Changed to Blocker as this bug is preventing us from rolling out Jenkins to production right now, but I could completely change our implementation and reduce this to Critical or Major I suppose, but that would be quite a bit of work) I start a parameterized build from project A via the build button. A second parameterized build from the same project was then started via the build button, but with different parameter values. Instead of having two jobs in the queue, the second job is not added and instead takes over the first job in the queue. If the jobs were started by different users, both users names show up as the "Started by" users. Only the second user's parameters are used and retained. The first user's job is just lost. I'm going to see if this ever worked, but I'm pretty sure it did. I'm still pretty new to Jenkins, but I thought I had tested this out before and had seen two instances of the same job sitting in the queue. |
| Priority | Original: Major [ 3 ] | New: Blocker [ 1 ] |
| Assignee | New: huybrechts [ huybrechts ] |
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.
| Priority | Original: Blocker [ 1 ] | New: Critical [ 2 ] |
| Description |
Original:
(Changed to Blocker as this bug is preventing us from rolling out Jenkins to production right now, but I could completely change our implementation and reduce this to Critical or Major I suppose, but that would be quite a bit of work) I start a parameterized build from project A via the build button. A second parameterized build from the same project was then started via the build button, but with different parameter values. Instead of having two jobs in the queue, the second job is not added and instead takes over the first job in the queue. If the jobs were started by different users, both users names show up as the "Started by" users. Only the second user's parameters are used and retained. The first user's job is just lost. I'm going to see if this ever worked, but I'm pretty sure it did. I'm still pretty new to Jenkins, but I thought I had tested this out before and had seen two instances of the same job sitting in the queue. |
New:
I start a parameterized build from project A via the build button. A second parameterized build from the same project was then started via the build button, but with different parameter values. Instead of having two jobs in the queue, the second job is not added and instead takes over the first job in the queue. If the jobs were started by different users, both users names show up as the "Started by" users. Only the second user's parameters are used and retained. The first user's job is just lost. I'm going to see if this ever worked, but I'm pretty sure it did. I'm still pretty new to Jenkins, but I thought I had tested this out before and had seen two instances of the same job sitting in the queue. |
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.