Gitlab workflow

[Matthew Pickering]

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://gitlab.haskell.org/ghc/ghc/merge_requests/1352
>
> 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/cgi-bin/mailman/listinfo/ghc-devs