Ah, so it was really two identical pipelines (one for the branch where Margebot batches commits, and one for the MR that Margebot creates before merging). That's indeed a non-trivial amount of purely wasted computer-hours.
Taking a step back, I am inclined to agree with the proposal of not checking stat regressions in Margebot. My high-level opinion on this is that perf tests don't actually test the right thing. Namely, they don't prevent performance drift over time (if a given test is allowed to degrade by 2% every commit, it can take a 100% performance hit in just 35 commits). While it is important to measure performance, and to avoid too egregious performance degradation in a given commit, it's usually performance over time which matters. I don't really know how to apply it to collaborative development, and help maintain healthy performance. But flagging performance regressions in MRs, while not making them block batched merges sounds like a reasonable compromise. On Wed, Mar 17, 2021 at 9:34 AM Moritz Angermann <moritz.angerm...@gmail.com> wrote: > *why* is a very good question. The MR fixing it is here: > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5275 > > On Wed, Mar 17, 2021 at 4:26 PM Spiwack, Arnaud <arnaud.spiw...@tweag.io> > wrote: > >> Then I have a question: why are there two pipelines running on each merge >> batch? >> >> On Wed, Mar 17, 2021 at 9:22 AM Moritz Angermann < >> moritz.angerm...@gmail.com> wrote: >> >>> No it wasn't. It was about the stat failures described in the next >>> paragraph. I could have been more clear about that. My apologies! >>> >>> On Wed, Mar 17, 2021 at 4:14 PM Spiwack, Arnaud <arnaud.spiw...@tweag.io> >>> wrote: >>> >>>> >>>> and if either of both (see below) failed, marge's merge would fail as >>>>> well. >>>>> >>>> >>>> Re: “see below” is this referring to a missing part of your email? >>>> >>>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
