-
Bug
-
Resolution: Fixed
-
Major
The "Build Current Patches Only" feature currently identifies previous builds based on their parameters as they were present when the build was first scheduled.
If you use a plugin that alters the parameters after the job has started, the cancelling of previous builds does not work, since the GerritTrigger#cancelJob() method does not find the job anymore.
This is easily and trivially fixed, by not scanning for the parameters, but instead for the GerritEvent that is stored in the GerritCause used to start a build.
A pull request has been uploaded here: https://github.com/jenkinsci/gerrit-trigger-plugin/pull/195
[JENKINS-26323] The "Build Current Patches Only" only works, if NO parameters in the build are altered
Code changed in jenkins
User: Robert Sandell
Path:
src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/GerritTrigger.java
http://jenkins-ci.org/commit/gerrit-trigger-plugin/2c0a52387aa9faaee4b6691a29850da6d9fd78ef
Log:
Merge pull request #195 from HedAurabesh/v2.13.0-abort-on-new-fix
JENKINS-26323 Fix "Build Current Patches Only" by scanning for event
Compare: https://github.com/jenkinsci/gerrit-trigger-plugin/compare/c3899eaf4e05...2c0a52387aa9
Code changed in jenkins
User: Martin Schroeder
Path:
src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/GerritTrigger.java
http://jenkins-ci.org/commit/gerrit-trigger-plugin/97b08eebefcc27a165063212fa7efefc66b89531
Log:
JENKINS-26323Fix "Build Current Patches Only" by scanning for eventThe "Build Current Patches Only" feature currently identifies previous
builds based on their parameters as they were present when the build was
first scheduled.
If you use a plugin that alters the parameters after the job has started,
the cancelling of previous builds does not work, since the
GerritTrigger#cancelJob() method does not find the job anymore.
This is easily and trivially fixed, by not scanning for the parameters, but
instead for the GerritEvent that is stored in the GerritCause used to start
a build.
The only downside to this is, that the current patch-set scans for identity,
but not equality of the two events. After a Jenkins restart, they might not
be identical anymore, since Jenkins reschedules queued builds and can't
unify the two events via Stapler; as they are stored in separate files.
It'd be trivially easy to alter this to Event.equals(otherEvent), in case
this degradation is not wanted.