tree 614f5fa92f953a4ce9ab788e94ea3b335c507142
parent 21c31bcb69c5fdf9a50b09ca0d372252ce6aefcb
author Brian Harring <ferringb@chromium.org> 1334966374 -0700
committer Brian Harring <ferringb@chromium.org> 1341527672 -0700

Refactor CQ logic around the concept of transactions.

Previous CQ behaviour basically was optimistic, but violated
some of the constraints it aimed for- for example, CQ-DEPEND
cycles weren't strictly enforced (two nodes, if one applied, one
didn't, the applied one would be left in place).

The code is now broken down into two phases; resolution of each
desired transaction, and application of each transaction, preferring
the transaction pulling in the most revs (working it's way down
to the smaller transactions- the notion being that long chains are
more of a pain to land, thus give them preference over one offs that
can quickly be rebased).

For the application phase, if a resolved transaction fails to apply,
the repo is *fully* restored to it's original state.  Effectively,
all or none for the commits in that transaction.  Since we generate
overlapping transactions, this isn't an issue for CQ mode- it'll
pick up the sub-transaction w/in the greater one, trying to apply that
(or skipping the sub-transaction if the greater transaction landed).

In this way, we can ensure that all constraints for a change landing
are properly honored.

W/in the resolution phases, we have two modes of operation; frozen,
and non-frozen.  Frozen is long term CQ behaviour (which is preserved);
only work from the patch pool it knows of.

For non frozen, this allows this code to arbitrary resolve gerrit/paladin
dependencies, querying as necessary.  This is required for
I60e1112c849f149f5c5ae0cc1ca6bd752bab72fd (which is a required step
to enable cherry-picking via Icd646d198721a916fd81effd31df30a70718210f).

Via the transaction support, it becomes possible for a patch to be tried
multiple times via separate transactions; this unfortunately required a
full overhaul of the error reporting for CQ; now, instead of assigning
messages onto the patch object itself (which could be involved in
multiple transactions, differing ways of being blocked from being
submitted), exceptions are thrown, chained together with the causes
of each step accessible.

That change unfortunately means that this patch cannot go through CQ
itself- it implicitly changes the pickle format for the 'conflicting_changes'
argument of ValidationPool, and cannot be done in a compatible fashion.  As
such testToTCompatibility is known to fail w/ this CL (it'll work after the
CL is in ToT), and to actually land this CL, we'll have to chump it in.
Is what it is frankly; there isn't a way around it in this case.

Finally, tests were heavily refactored, resulting in some minor
API shifts (renames for consistancy), and chunking the tests up
into logical groups of tests making it easier for debugging-
one starts with TestPatchSeries, then to TestCoreLogic, then to
user visible tests.  This was done since the ordering mentioned above
is literal- if PatchSeries is broken, everything descending from it
is going to misbehave.

BUG=chromium-os:27415, chromium-os:27256, chromium-os:29546
TEST=cbuildbot --remote x86-generic-paladin run
TEST=run_tests.sh; note that validation_pool_unittest.py fails
     testToTCompatibility; per message above, this is unavoidable.

Change-Id: I4325b5cf8ba0d48b21da9ae9043f95ec917c751f
Reviewed-on: https://gerrit.chromium.org/gerrit/20811
Tested-by: Brian Harring <ferringb@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>