Run the sync monthly, and on demand. If it goes through without needing
a human, push the libbpf-sync-* branch and open a pull request.
Otherwise fail the run without opening one.
The sync job runs code from the kernel trees (bpf_doc.py), so it only
gets a read-only token. A separate publish job pushes the verified sync
bundle and opens the pull request.
Skip the run while any sync pull request is open. Manual runs default
to dry runs, which only upload the sync results as an artifact.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Run sync-kernel.sh with stdin from /dev/null, so that any prompt asking
for human input fails the sync.
The exit code of sync-kernel.sh isn't reliable (e.g., it exits with 0
when interrupted), so tell from its output whether the sync went
through or there was nothing to sync.
On success, leave a bundle with the sync branch, patches and a pull
request description with the sync log in the output directory.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Set up a Linux repo the way sync-kernel.sh expects it: HEAD at
bpf-next's master and a bpf-master branch at bpf's master.
Fetch full history of both trees from the kernel-patches/bpf mirror on
GitHub, which is more reliable than git.kernel.org. The mirror may lag
behind, so don't require its branches to match git.kernel.org exactly,
only check that they're in the history of the master branches there.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Automatically comment on and close master-targeted pull requests that
touch kernel-synchronized libbpf paths. Keep mirror-only and unknown
paths open, with a github-only label for maintainer overrides.
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
github.head_ref is empty for push and schedule events, so all those
runs shared the same concurrency group and cancelled each other. Fall
back to github.run_id to give each non-PR run a unique group.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
The libbpf CI always builds the kernel from source at CHECKPOINT-COMMIT;
there is no prebuilt-kernel matrix entry. Remove the `kernel` input and
the conditional build-vs-download logic, simplifying the workflow.
The run-vmtest action defaults KERNEL to "LATEST" internally when the
env var is unset, so DENYLIST-LATEST is still picked up. The vmlinuz
path is auto-discovered via `make -s image_name` when not passed.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
run-on-arch-action is simply a wrapper around docker. There is no
value in using it in libbpf, as it is not complicated to run
non-native arch docker images directly on github-hosted runners.
Docker relies on qemu-user-static installed on the system to emulate
different architectures.
Recently there were various reports about multi-arch docker builds
failing with seemingly random issues, and it appears to boil down to
qemu [1]. I stumbled on this problem while updating s390x runners [2]
for BPF CI, and setting up more recent version of qemu helped.
This change addresses recent build failures on s390x and ppc64le.
[1] https://github.com/docker/setup-qemu-action/issues/188
[2] https://github.com/kernel-patches/runner/pull/69
[3] https://docs.docker.com/build/buildkit/#getting-started
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
* Don't run pahole@tmp.master + llvm-17 combination.
* Use descriptive name of for vmtest jobs
* Don't run test_progs_cpuv4 when LLVM_VERSION < 18 (same as on BPF CI)
* Add some logging to prepare-selftests-run.sh
Signed-off-by: Ihor Solodrai <ihor.solodrai@pm.me>
We are now getting:
WARNING: Module.symvers is missing.
Modules may not have dependencies or modversions.
You may get many unresolved symbol errors.
You can set KBUILD_MODPOST_WARN=1 to turn errors into warning
if you want to proceed at your own risk.
So let's set KBUILD_MODPOST_WARN=1.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Kernel/libbpf code is very well tested on s390x in BPF CI, so get rid of
it here as it often is a source of trouble and noise, without really
benefiting us much.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
As this will change to a Ubuntu 24.04 runner, we want this to automatically detect
which ubuntu version it is running on.
Signed-off-by: Manu Bretelle <chantr4@gmail.com>
I am working on upgrading to 24.04 runners. In order to make sure that current jobs are scheduled
on Ubuntu 20.04, we need to ask for runners with tag `docker-main`, which is currently
set by those old runners.
Later, we will be able to switch this tag to `docker-noble-main` which are Ubuntu 24.04 runners.
Signed-off-by: Manu Bretelle <chantr4@gmail.com>
pahole staging workflow is using the same old VM image as BPF selftests
stages. It doesn't have recent enough glibc, so we can't yet switch to
newer Ubuntu, unfortunately.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Track ubuntu-latest where relevant and possible.
We can't update to ubuntu-latest when building and running BPF
selftests, though, because our QEMU image has too old of an GLIBC.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Ihor Solodrai
Andrii Nakryiko
Ihor Solodrai
Ihor Solodrai
Jordan Rome
chantra
Manu Bretelle
Yonghong Song
Geyslan Gregório
Kui-Feng Lee