one merge run for multiple submits
Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
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  merge run has been triggered by this  change,
but by the time it got to cloning, 5 more changes were merged.
The next  merge run has been triggered by this  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  with ODL job config ,
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).
|1 - 1 of 1|