Hi Gert, > I can understand your frustration with the flaky tests,
My frustration comes as much from the Gitlab config as from the flaky tests. But you have a point: if tests weren't flaky this certainly wouldn't be much of a problem, and filing bugs is probably the best course of action to avoid them. > but I'm sure you know that having a CI is place helps a lot to not break most > of the code, so merging without having to go through the CI is not really an > option, even if we are all sensible adults. I don't follow the logic. Anybody with commit access can push from git command line bypassing any pipeline checks. We're already relying upon folks' judgment to use it only when it makes sense (e.g, crossporing commits, etc.) I don't see why having a UI button to automate makes a difference. Reassigning to marge-bot is easy enough, but IIUC that causes all pipeline stages (even those which were successful) to be repeated. I feel that's wasteful (not just money, but also energy.) Allowing one to Rebase + Merge on one click (like GitHub allows) would be more efficient IMHO. Anyway, for good or worse, I don't commit to Mesa as much as I used to, so this doesn't affect me nearly as much as others. Even though I believe allowing to merge without pipeline object would be an improvement, if everybody else is happy with the status quo, then don't mind me. Jose ________________________________ From: Gert Wollny <gw.foss...@gmail.com> Sent: Tuesday, September 21, 2021 15:32 To: Jose Fonseca <jfons...@vmware.com>; ML mesa-dev <mesa-dev@lists.freedesktop.org> Subject: Re: [Mesa-dev] Merge blocked Hello Jose, On Tue, 2021-09-21 at 11:48 +0000, Jose Fonseca wrote: > Why doesn't Gilab allow one to merge manually? > > See > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F12940&data=04%7C01%7Cjfonseca%40vmware.com%7C93aedc8ac8244272385008d97d0c9cfa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637678315394314865%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pIjQSUjrU7cCePEsmpcZ7qbdCFFhxZn0y3S7qSS8s7s%3D&reserved=0: > > * Marge-bot failed to merge the PR due to 2 flaky tests, completely > unrelated to the commits in question. I can understand your frustration with the flaky tests, but I'm sure you know that having a CI is place helps a lot to not break most of the code, so merging without having to go through the CI is not really an option, even if we are all sensible adults. Maybe we all should just file bugs when we see a flaky test, so that those get flagged accordingly by the developers responsible for the related drivers. > > * I manually retried the failed tests, and they all passed, but > still Gitlab refused to allow to merge: it said I needed to rebase. This is, because Marge merged some other MR between the time you rebased the last time. Since the pre-merge CI was added and before Marge was introduced, this actually happened quite regularly: Press the Merge-when-pipeline-succeeds button and fail, because some other merge request was already in the pipeline and got merged before your pipeline finished. However, nowadays you don't need to rebase yourself, once you assign the MR to Marge and she will do that for you when she starts to handle your merge request. > * I rebased, but still Gitlab refused to merge: now it expects the > pipelines to be runagain! I'm really sorry for your frustration, but if you're sure that the merge failed only because if flaky tests, then simply reassigning the MR to Marge will do. > Is it really necessary to go to git command line to get a PR > merged!? (I was forced to do so 2-3 times now, but it's a hassle.) No, it is not necessary, because Marge will do that for you, once you assign the MR to her. > Or run pipelines over and over until one eventually succeeds? This is only a problem because of the flaky tests, and yes, we should do something about this. > Sorry for the rant, but I didn't notice anybody else complain. Am I > the only bothered here? Or is there a better way here I don't know > of? As you sure have understood at this point, the answer is "Assign to Marge" ;) Best regards, Gert
