Gitlab workflow

Fri Jul 5 12:05:02 UTC 2019

Could Marge change the target branch of an MR before merging it? Perhaps
this would convince GitLab to show the right info.

On Fri, Jul 5, 2019, 6:18 AM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> |  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.
>
> OK.  The earlier one, also from Marge, not the Discussion stream but
> rather in the panel at the top, says
>
>     Closed by Marge Bot 8 hours ago
>     The changes were not merged into master
>
> So that is an outright lie?   Yes it is closed, but contrary to the
> statement it _has_ been merged.
>
> It's unfortunate that this misleading display is right at top, in the
> summary material, while the truth (that it has been merged) is buried in
> the Discussion stream.
>
> Alas.  But thank you for clarifying.
>
> Is this something we can raise with the Gitlab folk?  It seems so
> egregiously wrong.
>
> Simon
>
>
> |  -----Original Message-----
> |  From: Matthew Pickering <matthewtpickering at gmail.com>
> |  Sent: 05 July 2019 10:55
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Cc: ghc-devs <ghc-devs at haskell.org>
> |  Subject: Re: Gitlab workflow
> |
> |  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://gitl  >
> |  > | ab.haskell.org
> %2Fghc%2Fghc%2Fmerge_requests%2F1352&data=02%7C01%
> |  > | 7C  >
> |  > | simonpj%40microsoft.com
> %7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b
> |  > | f8  >
> |  > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=xZZiF
> |  > | zO  > 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
> |  > |  > http://mail.
> |  > |  >
> |  > | haskell.org
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C
> |  > | 01  >
> |  > | %7Csimonpj%40microsoft.com
> %7Ce03ba07f29c447c1252e08d7012c9b59%7C72f9
> |  > | 88  >
> |  > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=2a
> |  > | Xm  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&reserved=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190705/afbc407e/attachment.html>