Issue 3116: MergeValidationListener#onPreMerge is called at the wrong time
Status:  New
Owner: ----
Reported by andreas....@gmail.com, Jan 22, 2015
*****************************************************************
*****                                                       *****
***** !!!! THIS BUG TRACKER IS FOR GERRIT CODE REVIEW !!!!  *****
*****                                                       *****
***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, CYANOGENMOD,  *****
***** INTERNAL ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC.*****
*****                                                       *****
*****   THOSE ISSUES BELONG IN DIFFERENT ISSUE TRACKERS     *****
*****                                                       *****
*****************************************************************

Affected Version:

What steps will reproduce the problem?
1. Create a custom plugin that implements MergeValidationListener
2. Set project to "rebase if necessary"
3. Create two commits, independent from each other, but where the presence of the one will invalidate the other. Both are valid until the other has been merged. (This is the purpose of the plugin).
4. Submit the change that was pushed last (might work with either one)
5. Submit the other one
6. Gerrit does a rebase, forwards the +2 for code review and waits for the +1 for verification
7. Plugin seems to be called _before_ our Jenkins job does the verifying, and then once that is done the change is merged _without_ running the plugin.


What is the expected output? What do you see instead?
I expect the plugin to be run ABSOLUTELY last when merging a change. After After rebase, after verify, after review, after sorting of commits and so on. 

The goal of our plugin is to make sure that files that according to git/gerrit are unrelated but in fact are related never "collides". A simplified example could be that two text files could never at one time both contain the words "I'm the only one here!"


Please provide any additional information below.
We are running 2.9.1-11-gb4dbef6 wich I believe is exactly the same as 2.9.2 but built before it was officially released
Jan 22, 2015
Project Member #1 david.pu...@sonymobile.com
What state is the change in while it's waiting for the verified score?  Is the behaviour the same if the verification is done manually rather than by a triggered Jenkins job?

> The goal of our plugin is to make sure that files that according to git/gerrit are unrelated but in fact are related never "collides". A simplified example could be that two text files could never at one time both contain the words "I'm the only one here!"

I don't see how the plugin's result can be affected by it being invoked after the Jenkins verification.  Is the plugin still being invoked on the latest patch set (i.e. the one that was created by Gerrit's rebase)?

Jan 22, 2015
#2 andreas....@gmail.com
I've only looked at two changes that collided after it happend, I don't know the status while they were waiting for the verification.

The plugin will look at whats on master and that might changed during the time it takes jenkins to verify the rebased changed.