In zuul v2, prepareRef waited until the merger had completed its
work before telling the pipeline manager that the item was ready.
This was important as it ensured there was a zuul ref on a merger
for jobs to be able to fetch from. We dropped that in v3 because
the jobs would build their own repo states on the executor, however,
we're about to put something similar back in that we're going have
the merger return the complete repo state so that the executors can
later use that to reconstruct the work the merger performed.
Because prepareItem (essentially the v3 version of prepareRef) did
not wait for the merger result before declaring the item ready, we
can end up launching jobs before the merger completes. This isn't
a big deal, yet, but it could still produce surprising results and
make for extra work. This change restores the old behavior, as well
as makes a test less suceptible to race conditions (again, which
are more likely to be seen in future changes).
Similarly, we also lost setting ready to false in the case of a merge
conflict (a behavior which was present in v2). This corrects that
as well to ensure that we don't execute jobs if there is a merge
conflict.
Because some tests were written with the assumption that only one
merger is running, and we are now running two (a dedicated merger and
one in the executor), they are more likely to fail due to race
conditions, especially now that we are waiting for mergers to complete
before executing jobs. This change also removes the dedicated merger
from the test infrastructure so we rely only on the merger in the
executor.
Change-Id: I6d4da3d901d99290ef99b478ea9a4659058fe839
8d144dc4f8