On Thursday, January 16th, 2025 at 3:41 PM, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > 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? We can run daily, that's not an issue. I was thinking weekly, because there isn't much activity on the pahole side usually. > > > 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. Yeah, this is what I meant by using third-party action. The issue with it is that you need to provide mail server credentials, which are passed to a third-party code. So, to do that a bot-ty email account needs to be created and maintained somewhere. > > > 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 > > > > > [...]
