one merge run for multiple submits

Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)



For larger context, see today's discussion

on slack channel #fdio-infra.

TLDR: Bad things happened, we think because too many runs got scheduled.


Historically, merge jobs are not concurrent,

and they always checkout HEAD of $GERRIT_BRANCH.

In Jenkins that means if multiple Gerrit changes

are submitted in quick succession, multiple runs

of the merge job are scheduled, most of them

ending up building the same HEAD.


I know that merge jobs in OpenDaylight do not behave like that.

Instead of scheduling a run for each change,

at most one run is waiting in the queue,

effectively skipping building of non-last commits.

Example, copied from the slack channel:


  For example this [0] merge run has been triggered by this [1] change,

 but by the time it got to cloning, 5 more changes were merged.

 The next [2] merge run has been triggered by this [3] change,

 which was next in the chain. The "5 more" changes did not trigger their own runs.


But I was unable to figure out which configuration knob

makes the difference in merge job behavior.

I compared a vpp job config [4] with ODL job config [5],

but I see nothing obvious.

Incidentally, both jobs have string parameter GERRIT_REFSPEC,

even though the value is not used anywhere.


Is it something related to the timed trigger?

I know CSIT periodic jobs also avoid scheduling more than one run

(again without any obvious knob, except concurrent: false).