Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: subversion-plugin
-
Labels:
-
Similar Issues:
Description
Different values selected for 'List Subversion Tags' parameters are not considered in determining parameter equality.
ListSubversionTagsParameterValue needs to implement hashCode() and equals() properly.
Attachments
Issue Links
- links to
Activity
| Field | Original Value | New Value |
|---|---|---|
| Summary | Cannot add new build to queue from same project using different parameters | Cannot add new build to queue from same project with different parameters |
| Component/s | parameterized-trigger [ 15592 ] | |
| Component/s | 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 |
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. |
(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 | Major [ 3 ] | Blocker [ 1 ] |
| Assignee | 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 | Blocker [ 1 ] | Critical [ 2 ] |
| Description |
(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. |
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. |
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.
binary
added a comment - 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.
| Priority | Critical [ 2 ] | Major [ 3 ] |
We have the same problem with Jenkins 1.522
Krzysztof W
added a comment - We have the same problem with Jenkins 1.522 | Labels | build parameter queue | build parameter queue subversion |
| Component/s | core [ 15593 ] |
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?
| Component/s | parameters [ 15594 ] | |
| Component/s | subversion [ 15485 ] | |
| Component/s | parameterized-trigger [ 15592 ] | |
| Assignee | huybrechts [ huybrechts ] | |
| Description |
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. |
Update: Since this appears to be an issue with the selected branch, I think this is actually a bug in the Subversion plugin. ==================== 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. |
| Summary | Cannot add new build to queue from same project with different parameters | Jobs from same project are combined when different branches selected for each job |
| Description |
Update: Since this appears to be an issue with the selected branch, I think this is actually a bug in the Subversion plugin. ==================== 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. |
Update: Since this appears to be an issue with the selected branch, I think this is actually a bug in the Subversion plugin. ==================== (rewriting the description) When two different jobs from the same project are started by the same or different users and the only difference, besides possibly the user, is the branch/tag name, the jobs are combined in the queue and executed as a single job. This makes no sense though since user Jim could have selected branch "bugfix" and user Suzy could have selected branch "feature_1". Since Suzy was second, we end up only building "feature_1" and slapping both Jim and Suzy's names on the build. ======================= (original description) 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. |
| Description |
Update: Since this appears to be an issue with the selected branch, I think this is actually a bug in the Subversion plugin. ==================== (rewriting the description) When two different jobs from the same project are started by the same or different users and the only difference, besides possibly the user, is the branch/tag name, the jobs are combined in the queue and executed as a single job. This makes no sense though since user Jim could have selected branch "bugfix" and user Suzy could have selected branch "feature_1". Since Suzy was second, we end up only building "feature_1" and slapping both Jim and Suzy's names on the build. ======================= (original description) 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. |
Update: Since this appears to be an issue with the selected branch, I think this is actually a bug in the Subversion plugin. ==================== (rewriting the description) When two different jobs from the same project are started by the same or different users and the only difference, besides possibly the user, is the branch/tag name, the jobs are combined in the queue and executed as a single job. This makes no sense though since user Jim could have selected branch "bugfix" and user Suzy could have selected branch "feature_1". Since Suzy was second, we end up only building "feature_1" and slapping both Jim and Suzy's names on the build. Other build parameters prevent the jobs from being combined in the queue, but a branch/tag selected from the SVN plugin's drop down list does not. ======================= (original description) 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. |
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.
| Component/s | core [ 15593 ] | |
| Component/s | parameters [ 15594 ] | |
| Affects Version/s | current [ 10162 ] | |
| Description |
Update: Since this appears to be an issue with the selected branch, I think this is actually a bug in the Subversion plugin. ==================== (rewriting the description) When two different jobs from the same project are started by the same or different users and the only difference, besides possibly the user, is the branch/tag name, the jobs are combined in the queue and executed as a single job. This makes no sense though since user Jim could have selected branch "bugfix" and user Suzy could have selected branch "feature_1". Since Suzy was second, we end up only building "feature_1" and slapping both Jim and Suzy's names on the build. Other build parameters prevent the jobs from being combined in the queue, but a branch/tag selected from the SVN plugin's drop down list does not. ======================= (original description) 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. |
Different values selected for 'List Subversion Tags' parameters are not considered in determining parameter equality. ListSubversionTagsParameterValue needs to implement hashCode() and equals() properly. |
| Environment | Ubuntu 12.04 Server, VMWare Fusion |
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.
| Assignee | Daniel Beck [ danielbeck ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Remote Link | This issue links to "PR 87 (Web Link)" [ 11003 ] |
Any idea when this might be fixed Daniel?
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.
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
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)
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Workflow | JNJira [ 149841 ] | JNJira + In-Review [ 206754 ] |
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.