[libcxx-dev] [llvm-dev] Upcoming change with how libc++, libc++abi and libunwind are being built

[Mehdi AMINI via libcxx-dev]

On Wed, Oct 20, 2021 at 9:56 AM Louis Dionne <ldionne.2 at gmail.com> wrote:

>
>
> On Tue, Oct 19, 2021 at 1:39 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>>
>>
>> On Tue, Oct 19, 2021 at 9:37 AM Louis Dionne via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Oct 19, 2021 at 12:45 AM Michael Kruse <llvmdev at meinersbur.de>
>>> wrote:
>>>
>>>> Am Mo., 18. Okt. 2021 um 15:19 Uhr schrieb Louis Dionne <
>>>> ldionne.2 at gmail.com>:
>>>> > Nowadays, we handle all libc++'s own build bots through BuildKite at
>>>> https://buildkite.com/llvm-project/libcxx-ci.
>>>>
>>>> I didn't know. Good that there is systematic testing, but I am a bit
>>>> concerned about the fracturing of the CI infrastructure (Buildbot,
>>>> Green dragon, GitHub actions, Buildkite, ...)
>>>>
>>>
>>> For libc++/libc++abi/libunwind, it's actually quite simple. There's
>>> exactly one place to look, and it's BuildKite. And it runs systematically
>>> on all changes.
>>>
>>
>> Did you find a solution for having blamelist and blame emails on
>> BuildKite?
>>
>
> No, but I haven't tried. My experience so far has been that I've never had
> the need for a blamelist. Since we test everything pre-commit, you always
> know when one of your patch fails because you see it before it's been
> committed, in Phabricator. Actual breakage on main is incredibly rare
> nowadays and it pretty much only happens when someone (usually myself) is
> too keen on checking something in before CI is finished (oops!). There's
> never a lot of suspicious commits on main since the last build, so this
> isn't a problem we've encountered.
>
> I guess your experience can vary based on the commit traffic to the
> project and how diligent people are at testing everything pre-commit, of
> course.
>

There are other aspects:
- as the commit traffic increases, you can't necessarily test everything in
sequence (Rust does, but their maintainers also have to manually bundle
pull-request together: they are limited to ~7 merges per day), so
concurrent merges can interact with each other and break master.
- as the matrix of configurations increase, it does not seems possible to
just test everything (HW: PPC, SystemZ, X86, Arm, Arm64, Risc  *TIMES* the
OSes Mac, Windows, Linux, FreeBSD *TIMES* the host compilers gcc 5/6/7/...,
clang, MSVC, ... *TIMES* sanitizers build), plus some things like the
multi-stages bootstrap and such.

So in practice yeah I believe blamelist and notification are a must for
LLVM and the monorepo, libc++ may be "too small" to be representative of
the scale there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20211020/50322e0e/attachment.html>