arnaud.spiwack at tweag.io
Wed Mar 17 09:53:28 UTC 2021
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
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.angermann at gmail.com>
> *why* is a very good question. The MR fixing it is here:
> On Wed, Mar 17, 2021 at 4:26 PM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> Then I have a question: why are there two pipelines running on each merge
>> On Wed, Mar 17, 2021 at 9:22 AM Moritz Angermann <
>> moritz.angermann at 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.spiwack at tweag.io>
>>>> and if either of both (see below) failed, marge's merge would fail as
>>>> Re: “see below” is this referring to a missing part of your email?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs