Commit Graph

161 Commits

Author SHA1 Message Date
Xavier Morel
0a64699070 [FIX] forwardport: cached repo setup
Turns out bare repositories (unlike normal ones) don't have any
refspecs by default. So adding the PR refspec would... replace the
default behaviour (apparently?) and the base branches would never get
fetched at all.

--mirror looks to be an other option as it has a default refspec but
it's a bit of an odd duck: it has pull requests in refs/pull but not
all of them? And open / closed doesn't seem to be a factor.
2019-09-12 15:03:45 +02:00
Xavier Morel
60f4db8687 [FIX] forwardport: forgot token when getting PR commits
So would break any time it needed to fetch the commits of a PR in a
private repo.
2019-09-12 14:35:56 +02:00
Xavier Morel
426bc69ea1 [FIX] forwardport: ask github what the PR's commits are
Attempts to use rev-list seem to work locally but they fail *a lot*
when live. The previous attempt to fix it in
0f4c22490c made things worse rather than
better once deployed.

Give up on that (at least for now?), and just ask github what the PR's
commits are then cherrypick exactly that.
2019-09-12 11:58:10 +02:00
Martin Trigaux
48c8e53df2 [FIX] forwardport: clarify forward port message
The ping message was not clear
- don't know if anything is needed from the author
- don't know if the last step in the chain

Ping the authors only when something needs to be done (error or last
step).

Do not ping non-reviewers as they will not have the rights to r+ or
modify the PR anyway

Closes #192
2019-09-12 09:05:49 +02:00
Xavier Morel
0f4c22490c [IMP] forwardport: refs
There's an issue of too many commits being selected for
cherry-picking. It still isn't quite clear, but the forward ports to
11.0 systematically seem to get everything from
5045b5f4c346e60c9b127403ef1fde453d49396a to the PR head, and that
commit was one of the first to land after the last merge-based forward
port.

So the commits selection seems to behave as if the commits range was
`..origin/pull/36692` rather than the `origin/10.0..origin/pull/36692`
which is passed to rev-list. This might be an issue of concurrent
access / update of the refs (though I can't reproduce it locally,
missing refs generate an error).

This change attempts to "pin" the local branch in the working copy
rather than go and get it from the repo. It's unclear that this will
change / fix anything, but it might just work.

Also stop creating shared clones, that seems like an unnecessary
risk (and might be the actual source of the issue).
2019-09-12 09:05:49 +02:00
Xavier Morel
a69ed7996a [FIX] forwardport: change method for conflicting working copy
The original method was to `git diff | git apply` in order to get a
complete overview of conflicts generated by the forward port (if
any).

However this turns out to have a huge issue in the presence of renamed
or removed files: in that case `git apply` will simply not do
anything, and fail with a completely clean working copy. Which is very
much undesirable.

-> alternative method, squash the PR to a single commit then
cherry-pick that single commit, this should provide us with proper
conflicts & their markers.

Also add tests for conflicts due to deleted files...
2019-09-12 09:05:49 +02:00
Xavier Morel
0e3d873f0f [IMP] forwardport: logging & rename during cherrypick
* add slightly better logging to the cherrypick process (init)
* cherrypick with an infinite renamelimit, seems fine according to
  linus[0] and significantly reduces "unsuccessful" forward ports

[0] http://git.661346.n2.nabble.com/Merging-limitations-after-directory-renames-interesting-test-repo-td6041103.html#a6041833
2019-09-12 09:05:49 +02:00
Xavier Morel
4ce4a3bda7 [FIX] forwardport: disable creation of draft PRs
That was only indicative and it doesn't work on private repos.
2019-09-12 09:05:49 +02:00
Xavier Morel
4fcebed563 [FIX] forwardport: PR message
* avoid losing original PR message
* add PR source to description
2019-09-10 09:54:25 +02:00
Xavier Morel
79777662df [FIX] forwardport: clone op and add logging 2019-09-10 09:28:30 +02:00
Xavier Morel
f671dcc828 [ADD] forwardbot
* Cherrypicking is handrolled because there seems to be no easy way to
  programmatically edit commit messages during the cherrypicking
  sequence: `-n` basically squashes all commits and `-e` invokes a
  subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it
  interrupts the process before each commit), however there doesn't
  seem to be clean status codes so it's difficult to know if the
  cherrypick failed or if it's just waiting for a commit of this step.

  Instead, cherrypick commits individually then edit / rewrite their
  commit messages:

  * add a reference to the original commit
  * convert signed-off-by to something else as the original commit was
    signed off but not necessarily this one

* Can't assign users when creating PRs: only repository collaborators
  or people who commented on the issue / PR (which we're in the
  process of creating) can be assigned.

  PR authors are as likely to be collaborators as not, and we can have
  non-collaborator reviewers. So pinging via a regular comment seems
  less fraught as a way to notify users.
2019-09-05 10:00:07 +02:00