On Wed, Jan 15, 2025 at 1:06 PM Ihor Solodrai <ihor.solodrai@xxxxx> wrote: > > 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. Why not daily? I was even thinking of running it as part of patch testing to catch regressions as early as possible, but then we'd have red CI for any small pahole regression, which would be cumbersome. So perhaps a daily separate run that wouldn't affect upstream patches? > > 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. Can you send email from inside the CI itself? E.g., if pahole build fails or selftests fail, explicitly send email before failing CI run? Just one idea, don't have anything better. > > 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 > > > > > [...] > >
