Gitlab workflow

[Matthew Pickering]

It's not possible to make the MR status merged and also have a
reliable merge bot. We used to try to make the status merged but it
caused too much instability.

Merge trains might eventually work but the current iteration is not
suitable as it doesn't work with forks.

You believe the one which marge posts telling you that the patch is
merged, the commit it links to is on master so you can clearly see the
patch has been committed.

Matt

On Fri, Jul 5, 2019 at 10:43 AM Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> |  No it is not possible due to the use of Marge to merge patches. Gitlab
>
> By "it" is not possible, you mean that it's not possible to make the MR status into "Merged". Worse, I think you are saying that some MRs will say "Merged" and some will say "Closed" in some random way depending on Marge batching.  Sigh.
>
> Maybe this will get better with Gitlab's new merge-train feature.
>
> Meanwhile, my original message also asked why the MR shows two contradictory messages about whether the MR has landed.  Is that also un-fixable?   And if so how do I figure out which one to believe?
>
> Thanks
>
> Simon
>
>
>
> |  -----Original Message-----
> |  From: Matthew Pickering <matthewtpickering at gmail.com>
> |  Sent: 05 July 2019 10:39
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Cc: ghc-devs <ghc-devs at haskell.org>
> |  Subject: Re: Gitlab workflow
> |
> |  Hi Simon,
> |
> |  No it is not possible due to the use of Marge to merge patches. Gitlab
> |  automatically chooses the merged status as follows:
> |
> |  Consider two MRs both which target HEAD.
> |
> |  MR 1: HEAD <- A
> |  MR 2: HEAD <- B
> |
> |  Marge creates a batch which contains both MR 1 and MR 2. Once the batch
> |  succeeds, firstly MR 1 is merged.
> |
> |  HEAD <- A
> |
> |  MR 1 is closed with the *merged* status because A was merged directly
> |  into HEAD and it matches the state of MR 1.
> |
> |  Then patch B gets merged and now master looks like:
> |
> |  HEAD <- A <- B
> |
> |  MR 2 is closed with closed status because B was merged into master after
> |  A, not directly onto HEAD (as the original MR was).
> |
> |  There is no option to change this status in the gitlab API.
> |
> |  Cheers,
> |
> |  Matt
> |
> |  On Fri, Jul 5, 2019 at 8:38 AM Simon Peyton Jones via ghc-devs <ghc-
> |  devs at haskell.org> wrote:
> |  >
> |  > Ben
> |  >
> |  > Still trying to understand GitLab.  Look at MR 1352
> |  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&data=02%7C01%7C
> |  > simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988bf8
> |  > 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=xZZiFzO
> |  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&reserved=0
> |  >
> |  > It clearly says on the first page “The changes were not merged into
> |  master”
> |  > But lower down (at the end) it says “Merged in 80af...”
> |  >
> |  > What should I believe? Merged or not merged?
> |  >
> |  > Also
> |  >
> |  > It would be really helpful if a MR status, displayed prominently at the
> |  top, had “Merged” as a status, not just “Closed”.  If I’m trying to check
> |  if my has landed, and I see “Closed”, that could mean that someone has
> |  (doubtless for good reasons) closed it manually, and that it will never
> |  land.
> |  >
> |  > Would that be possible?
> |  >
> |  > Thanks
> |  >
> |  > Simon
> |  >
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
> |  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01
> |  > %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988
> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=2aXm
> |  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&reserved=0