Re: On CI

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 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 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.angermann@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 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?