My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2634: Gerrit events should expose the kind of change
6 people starred this issue and may be notified of changes. Back to list
Status:  Released
Owner:  ----
Closed:  May 2014


Sign in to add a comment
 
Reported by pedah...@gmail.com, May 2, 2014
Copying and pasting from my exchange with Dave Borowitz.

> We recently implemented
>
> label.Label-Name.copyAllScoresIfNoCodeChange
>
> For our Code-Review and Verified labels.  It works as designed! Thanks!
>
> The problem is that the Jenkins Gerrit Trigger still sees the new change
> set,
> and begins another build.  Is there a way to tell Gerrit not to send and
> event
> in the case of NoCodeChange?


I don't think this is desirable. Gerrit Trigger might not be interested in
NO_CODE_CHANGE events but other consumers might be.

> On the other side of the coin, while it would be
> a change to Gerrit Trigger, is there any way Gerrit Trigger would know
> that it
> is just a commit message change, and not a code change? That is, is there
> anything thing in the message payload sent to the trigger that would
> indicate
> there has been no code change?
>

I think it would be reasonable to expose the change kind (REWORK,
TRIVIAL_REBASE, NO_CODE_CHANGE) in the event itself so that consumers don't have to replicate Gerrit's logic.

Could we modify the event payload to include this kind of information?
May 12, 2014
Project Member #1 David.Os...@gmail.com
(No comment was entered for this change.)
Status: Accepted
May 14, 2014
Project Member #2 dougk....@gmail.com
It should be possible to expose this data -- the ApprovalCopier class has all the logic to get the change kind, and it would be a matter of using that in the ChangeHookRunner to output the change kind (along with the appropriate changes to the JSON structures that are output over stream-events and the hook commands.
May 14, 2014
#3 pedah...@gmail.com
Just a random question (since I had no idea of the format of the change event; appears to be JSON): Will this break anything backward compatibility wise? Orr will it simply have an extra attribute that, for example, Jenkin's Gerrit Trigger will simply ignore?
May 14, 2014
#4 dborowitz@google.com
As discussed on IM, factoring out logic from ApprovalCopier is fine but given that it calls getChangeKind in a loop means the amount you'd actually be able to factor out might not be as much as you think.

I can't speak specifically for the Jenkins Gerrit Trigger plugin but generally speaking JSON parsers are able to ignore unknown fields.
May 16, 2014
Project Member #5 edwin.ke...@gmail.com
https://gerrit-review.googlesource.com/57231
Status: ChangeUnderReview
May 19, 2014
Project Member #6 edwin.ke...@gmail.com
 Issue 2559  has been merged into this issue.
May 29, 2014
Project Member #7 dougk....@gmail.com
This has been merged into master.
May 29, 2014
Project Member #8 david.pu...@sonymobile.com
(No comment was entered for this change.)
Status: Submitted
Labels: FixedIn-2.10
Jun 2, 2014
#9 pedah...@gmail.com
Will this be merged into 2.9 as well?
Jun 2, 2014
Project Member #10 edwin.ke...@gmail.com
> Will this be merged into 2.9 as well?
No, it will only be part of Gerrit 2.10.
2.9 is already pretty close to the final release and only important fixes will be accepted for it, but no new features.
Jan 27, 2015
Project Member #11 ziv...@gmail.com
(No comment was entered for this change.)
Status: Released
Sign in to add a comment

Powered by Google Project Hosting