Re: Announcement: GCC BPF is now being tested on BPF CI

[Sam James <sam@gentoo.org>]

Ihor Solodrai via Gcc <gcc@gcc.gnu.org> writes:

> On Friday, January 17th, 2025 at 2:44 AM, Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
>
>> [...]
>>
>> > Ok. I disabled the execution of the test_progs-bpf_gcc test runner for now.
>> > 
>> > I think we should check on the state of the tests again after decl_tags
>> > support is landed.
>> 
>> 
>> Thank you. Sounds like a plan :)
>> 
>> Is it possible to configure the CI to send an email to certain
>> recipients when the build of the selftests with GCC fails? That would
>> help us to keep an eye on the patches and either fix GCC or provide
>> advise on how to fix the selftest in case it contains bad C.
>
> In principle, yes. In practice email notifications are not that
> straightforward.
>
> Currently a BPF patch submitter gets a notification about the status
> of the CI pipeline for their patch. This makes sense, recipient is
> obvious in this case.
>
> In case of GCC (or any other CI dependency for that matter), it is
> necessary to determine the potential cause before sending
> notifications. There are all kinds of things that might have caused a
> failure independent of the target being tested: could be a bug in CI
> scripts, or github could have changed runner configuration, or a merge
> commit from (Linux) upstream broke something, etc.
>
> Point is, dependency maintainers (GCC team in this case) don't want to
> get notifications for *all* such failures, because you will have to
> ignore most of them, and so they become noise. A boy crying wolf kind
> of thing.
>
> The other issue is that maintaining email notifications is an
> operational overhead, meaning that the system managing the
> notifications needs to be looked after. Currently for BPF CI it's
> Kernel Patches Daemon instance maintained by Meta engineers [1].
>
> As it stands, if there is problem with GCC that affects BPF CI, you
> can be assured it'll be reported, because it will block the testing of
> the BPF patches.
>
> I suggest GCC BPF team to think about setting up your own automated
> testing infrastructure, focused on testing the GCC compiler. Maybe you
> already have something like that, I don't know. You certainly
> shouldn't rely exclusively on BPF CI for testing the BPF backend.

I think Jose is asking from the angle of wanting to make GCC support as
painless as possible for you upstream, not to ask you to provide a
substitute for our own CI. i.e. We don't want you to feel burdened by
providing that and we're happy to look into any problems as soon as they
arsie.

>
> [1] https://github.com/facebookincubator/kernel-patches-daemon
>
>> 
>> > Thanks.
>> > 
>> > [...]