Commit Graph

224 Commits

Author SHA1 Message Date
Xavier Morel
e98a8caffb [FIX] runbot_merge: ensure all staging branches are built/tested
Before this change, when staging batches only affecting one repo (of n)
the unaffected repositories would get a staging branch exactly matching
the target.

As a result, either runbot_merge or runbot would simply return the
result of an unrelated build, potentially providing incorrect
information and either failing a staging which should have succeeded
(e.g. change in repo A broke B, PR is making a change in repo A which
fixes B, but B's state is reported as the previous broken build) or
succeeding a staging which should have failed (change in repo A breaking
B except a previous build of the exact same B succeeded with a different
A and is returned).

To fix this issue, create a dummy commit at the head of each staging
branch. Because commit dates are included in the hash and have a second
precision it's pretty unlikely that we can get built duplicates, but
just to be completely sure some random bits are added to the commit
message as well.

Various tests fixed to correctly handle the extra dummy commit on
staging branches.

fixes #35
2018-09-11 10:21:24 +02:00
Xavier Morel
a40b4c20da [ADD] runbot_merge: flag to disable rebase before merge
rebase-and-merge (or squash-merge if pr.commits == 1) remains default,
but there are use cases like forward ports (merge branch X into branch
X+1 so that fixes to X are available in X+1) where we really really
don't want to rebase the source.

This commits implements two alternative merge methods:

If the PR and its target are ~disjoint, perform a straight merge (same
as old default mode).

However if the head of the PR has two parents *and* one of these
parents is a commit of the target, assume this is a merge commit to
fix a conflict (common during forward ports as X+1 will have changed
independently from and incompatibly with X in some ways).

In that case, merge by copying the PR's head atop the
target (basically rebase just that commit, only updating the link to
the parent which is part of target so that it points to the head of
target instead of whatever it was previously).
2018-09-03 13:16:36 +02:00
Xavier Morel
6d7c728471 [CHG] runbot_merge: toggle default merge method to rebase-and-merge
After discussion with al & rco, conclusion was default PR merging method
should be rebase-and-merge for cleaner history.

Add test for that scenario (w/ test for final DAG) and implement this
change.
2018-09-03 13:16:36 +02:00
Xavier Morel
0afe8797f4 [IMP] runbot_merge: avoid unnecessary fetches
* avoid fetching PRs for un-managed branches if we know up-front
* avoid processing comments with no commands (avoids fetching the
  corresponding PR which we know nothing about yet and which may or
  may not be for a managed branch)
2018-09-03 13:16:36 +02:00
Xavier Morel
cab683ae0f [IMP] runbot_merge: remove "sync PRs", fetch unknown PRs
The old "sync pr" thing is turning out to be a bust, while it
originally worked fine these days it's a catastrophe as the v4 API
performances seem to have significantly degraded, to the point that
fetching all 15k PRs by pages of 100 simply blows up after a few
hundreds/thousands.

Instead, add a table of PRs to sync: if we get notified of a
"compatible" PR (enabled repo & target) which we don't know of, create
an entry in a "fetch jobs" table, then a cron will handle fetching the
PR then fetching/applying all relevant metadata (statuses,
review-comments and reviews).

Also change indexation of Commit(sha) and PR(head) to hash, as btree
indexes are not really sensible for such content (the ordering is
unhelpful and the index locality is awful by design/definition).
2018-09-03 13:16:36 +02:00
Xavier Morel
76c4d24bf5 [IMP] runbot_merge: don't create unstaged stagings
Previously when splitting staging we'd create two never-staged
stagings. In a system where the stagings get deleted once done
with (succeeeded or failed) that's not really important, but now that
we want to keep stagings around inactive things get problematic as
this method gunks up the stagings table, plus the post-split stagings
would "steal" the original's batches, losing information (relation
between stagings and batches).

Replace these empty stagings with dedicated *split* objects. A batch
can belong to both a staging and a split, the split is deleted once a
new staging has been created from it.

Eventually we may want to make batches shared between stagings (so we
can track the entire history of a batch) but currently that's only
PR-level.
2018-09-03 13:16:36 +02:00
Xavier Morel
8bc90283f8 [IMP] runbot_merge: stop deleting batches & stagings
If we want a dashboard with a history of stagings, maybe not deleting
them would be a good idea.

A replacement for the headless stagings would probably be a good idea:
currently they're created when splitting a failed staging containing
more than one batch, but their only purpose is as splits of existing
batches to be deactivated/deleted to be re-staged (new batches &
stagings are created then as e.g. some of the batches may not be
merge-able anymore) and that's a bit weird.
2018-09-03 13:16:36 +02:00
Xavier Morel
3b0a794c7b [ADD] runbot_merge: trivial dashboard 2018-09-03 13:16:36 +02:00
Xavier Morel
6494ea6cb0 [ADD] runbot_merge: webhook signature support 2018-09-03 13:16:36 +02:00
Xavier Morel
0725c77323 [IMP] runbot_merge: logging of comment commands (or lack thereof) 2018-09-03 13:16:36 +02:00
Xavier Morel
f67bdd8c5e [FIX] runbot_merge: incorrect relation name in M2O 2018-09-03 13:16:36 +02:00
Xavier Morel
5e64f79730 [ADD] runbot_merge: update squash flags when PR commits are updated
If the PR's commits count changes, the squash state should be updated
to match/reflect.
2018-09-03 13:16:36 +02:00
Xavier Morel
df2d19302b [REM] runbot_merge: support for squash+/squash-
AL thinks it's not useful and it's better to always squash/rebase a
single commit & merge multiple. Mark tests as xfail'd instead of
removing them.

Also mark test_edit_retarget_managed as skipped explicitly
2018-09-03 13:16:36 +02:00
xmo-odoo
7233179d6a [FIX] runbot_merge: only cancel active staging on p=0
Not when any priority is set on any PR…
2018-09-03 13:16:36 +02:00
Xavier Morel
9286b346e8 [FIX] runbot_merge: IDE warnings 2018-09-03 13:16:36 +02:00
Xavier Morel
34497a91b4 [FIX] runbot_merge: don't try to stage urgent PRs in error 2018-09-03 13:16:36 +02:00
Xavier Morel
47428a4580 [IMP] runbot_merge: only label PR if not created merged/closed
Would generate a ton of GH API churn when synchronising.
2018-09-03 13:16:36 +02:00
Xavier Morel
39a0d723af [ADD] runbot_merge: tag PR to signify state changes 2018-09-03 13:16:36 +02:00
Xavier Morel
49c8fdbed2 [IMP] runbot_merge: prioritize p0 more
* p0 cancel existing stagings in order to be staged as soon as
  possible
* p0 PRs should be picked over split batches
* p0 bypass PR-level CI and review requirements
* p0 can be set on any of a batch's PR, matched PRs will be staged
  alongside even if their priority is the default
2018-09-03 13:16:36 +02:00
Xavier Morel
e6f5b84a19 [IMP] runbot_merge: add PR ID to commit message when merging 2018-09-03 13:16:36 +02:00
Xavier Morel
ea9203c359 [IMP] allow delegate reviewers to retry and r- 2018-09-03 13:16:36 +02:00
Xavier Morel
781b679648 [FIX] runbot_merge: de-f-string-ify 2018-09-03 13:16:36 +02:00
Xavier Morel
933559da04 [IMP] runbot_merge: repos shoud be unique
Having the same repository in two different projects makes no sense,
the two projects will conflict with one another.
2018-09-03 13:16:36 +02:00
Xavier Morel
e52d08ecdf [ADD] runbot_merge: a merge bot
No actual dependency on runbot, should be usable completely
independently.
2018-09-03 13:16:36 +02:00