Am Freitag, den 15.05.2020, 21:32 +0200 schrieb Jonas Hahnfeld: > Am Freitag, den 15.05.2020, 16:57 +0100 schrieb Kevin Barry: > > On Fri, May 15, 2020 at 04:25:52PM +0200, Jonas Hahnfeld wrote: > > > That the script is doing exactly what I told it to do: The diff between > > > the previous and the rebased commit is not empty. Therefore it adds the > > > Patch::new label, removing Patch::push. > > > > Shouldn't `diff staging...HEAD` be the same before and after a rebase > > (three dots)? > > Yes, I think this works as long as staging not already includes some > (rebased) commits that were previously part of the merge request. We > could of course determine the merge base between the old and new commit > which should also avoid that case.
My thinking was wrong here: The common merge base of the two commits results in a larger diff for the new commit because it now includes all commits since the merge base, which is not what we want. So I went with Kevin's original suggestion with one modification: The staging branch is a moving target. Depending on when the webhook runs, the rebased commits might have already landed which makes the diff empty. Instead I ask GitLab for the diffs relative to the respective base commits. I think this does the right thing (tm), at least in my testing. I already deployed the change to my server, here for reference: https://gitlab.com/lilypond/infrastructure/-/merge_requests/4 Testing in the repo and feedback would be welcome! Jonas
signature.asc
Description: This is a digitally signed message part
