Hi.

For larger context, see today's discussion

on fd.io 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 FD.io 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).

Vratko.

[0] https://jenkins.opendaylight.org/releng/view/Merge-Jobs/job/controller-maven-merge-master/204/

[1] https://git.opendaylight.org/gerrit/c/controller/+/91723

[2] https://jenkins.opendaylight.org/releng/view/Merge-Jobs/job/controller-maven-merge-master/205/

[3] https://git.opendaylight.org/gerrit/c/controller/+/91756

[4] https://jenkins.fd.io/view/vpp/job/vpp-arm-merge-master-ubuntu1804/configure

[5] https://jenkins.opendaylight.org/releng/view/Merge-Jobs/job/controller-maven-merge-master/configure