On Friday, January 10th, 2025 at 7:58 AM, Ihor Solodrai <ihor.solodrai@xxxxx> wrote: > > On Friday, January 10th, 2025 at 5:51 AM, Arnaldo Carvalho de Melo acme@xxxxxxxxxx wrote: > > > On Fri, Jan 10, 2025 at 02:31:41AM +0000, Ihor Solodrai wrote: > > > > > BPF CI caught a segfault on aarch64 and s390x [1] after recent merges > > > into the master branch. > > > > In the past the libbpf github actions was tracking the tmp.master (it would > > be better to track "next") branch and I was looking at when it passed to > > then move "next" to master, that would be great to have so that we > > wouldn't be having these bugs in the git history, avoiding force pushes. > > > libbpf CI is still tracking tmp.master: > > https://github.com/libbpf/libbpf/actions/runs/12696027660/job/35389206487 > > However it only runs once a day. BPF CI runs more frequently due to the > volume of incoming patches. As of recently, BPF CI has been using "master". > Yesterday, when I saw the failures, I switched BPF CI to v1.28. > > I think the right way to approach this is for libbpf/libbpf to track "next", > and BPF CI use "master". Then, most importantly, only merge next into master > after libbpf CI has passed. > > This can potentially be automated, but would require push access to the > pahole repo. Until then, a maintainer would need to manually check the > libbpf CI status here: > > https://github.com/libbpf/libbpf/actions/workflows/test.yml > > Another thing is that libbpf CI only tests x86_64 currently. > We could add aarch64 to libbpf, or migrate pahole staging job to > kernel-patches/vmtest (which is almost identical to BPF CI). Hi everyone. I looked into adding aarch64 to libbpf/libbpf CI: we can't do that because Github does not provide hosted Linux aarch64 runners, only macs [1]. Since BPF CI already has all the infrastructure in place, I figured it's going to be relatively easy to set up an additional workflow specifically for pahole. Here is how it looks like: https://github.com/kernel-patches/vmtest/actions/runs/12796621827 This is basically a simplified BPF CI run: build pahole, build kernel with gcc, build selftests/bpf with clang-18 and run test_progs (only one runner, but we can run more if appropriate). I am thinking to set it up to run once a week, testing pahole/next. If we do that, tmp.master tracking on libbpf/libbpf can be removed. I also thought about email notifications to dwarves list, like we have for BPF CI. Unfortunately, there is no nice-and-easy way to set this up: we either have to maintain a dummy email account and use a third-party action (like [2]), or we could add a code path to Kernel Patches Daemon that currently handles BPF CI notifications. I don't like either way. Alternatively, maintainers could subscribe to github notifications on kernel-patches/bpf (aka "watch"), but that might be too noisy as there is a lot of activity there. Of course, you could check the CI runs without any notifications too. Alan, Arnaldo, Andrii, please let me know if you have any suggestions or objections. [1] https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories [2] https://github.com/marketplace/actions/send-email > > [...]
