A user wants to be able to send core-review +2 for a specific job even though other jobs may be triggered for the same event. Currently, the resulting core-review value sent is 0.
The setup required to be able to have 2 jobs (ABC and DEF) send different label values is as follows:
- At the global level, the value for code review on Build Successful defaults to 0.
- At the global level, the value for verified on Build Successful defaults to 1.
- Job DEF is configured to send code-review = 2 on Build Successful
When the jobs are triggered, the resulting command to send to Gerrit that is built by the Gerrit Trigger contains:
--verified 1 --code-review 0
This is perceived as incorrect since we have asked for the code-review = 2
However, the Gerrit Trigger works as follows:
- The build from Job ABC finishes and the code review value is determined to be 0 since the job has not overridden the default.
- The build from Job DEF finished and the code review value is determined to be 2 since it has overridden the default.
- The plugin then calculates a minimum value between the 2 values and hence determines it to be 0
In this case, it would make sense to alter the behavior to not allow jobs that have not overridden code review on Build Successful to contribute to the final value of code-review.
Even, if we can change this behavior, the situation is further complicated by the fact that:
The command to send is built using a command template that contains "--code-review <CODE REVIEW>"
Gerrit Trigger will expand the above string to insert the correct value.
In the case where 2 jobs have not overridden the default, it would make sense to remove the entire string "--code-review <CODE REVIEW>" from the command to send. Doing this would not be straightforward.
Way forward #1
- Alter the behavior to not allow jobs that have not overridden code review on Build Successful to contribute to the final value of code-review.
- This means that we can have one Jenkins job setting only the Verified label to +1 or -1 and another Jenkins job setting only Code-review label to +1 or -1 for the same patch-set in Gerrit.
- We could decide the send a default of 0 when no jobs have overridden the default.
Way forward #2
In order to fix this properly, major rework would be required within the Gerrit Trigger plugin. The work would be in the context of support Custom Labels and the code-review would be added and treated as such. This improvement has already been mentioned here: JENKINS-27873
The work would involve a re-work of the config UIs and a refactoring of the Notifying classes.
This would be very interesting as it would further enhance the integration between Jenkins and Gerrit by making the submission of changes more readily possible to automate.