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 <[email protected]> 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 <[email protected]> > | Sent: 05 July 2019 10:39 > | To: Simon Peyton Jones <[email protected]> > | Cc: ghc-devs <[email protected]> > | 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- > | [email protected]> 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 > | > [email protected] > | > 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 _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
