Ihor Solodrai via Gcc <gcc@gcc.gnu.org> writes: > On Friday, January 17th, 2025 at 2:44 AM, Jose E. Marchesi > <jose.march...@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. >> > >> > [...]
