Repository navigation
ci(test-install): build and install the current stable kernel (#43) - #60
Merged
Merged
Conversation
…d#43) The install matrix only ever built 6.12.112, the default kernel_version. Kernel.org's stable release moves on its own, so a break that only shows up on current kernels (like the Fedora elfutils-devel BuildRequires that landed in Linux 6.15) stayed green in CI. Add a `latest-install` job that runs `./kernel_installer.sh` with no arguments and reads the installed release back from the build output, asserting it is neither the pin nor something the packaging layer rewrote. It covers Fedora 44 and Debian 13 and runs weekly on a schedule plus workflow_dispatch, so a new kernel that breaks the build shows up without anyone opening a PR. The pinned jobs keep their 6.12.112 matrix for reproducible PR checks and are skipped for the schedule event. The concurrency group now includes the event name so the weekly run cannot cancel an in-flight main or PR run on the same ref.
The no-argument install resolves the current stable version from kernel.org with curl or wget, and debian:13 ships neither: the job died in seconds with "Could not determine a valid kernel version (got: ''). Check your network connection", which looked like a network problem instead of a missing prerequisite. Reproduced in debian:13 with the job's prerequisite set: exit 1 with an empty banner, and the resolve succeeds as soon as curl is installed. Add curl to both container branches; the dnf branch lists it explicitly rather than relying on the fedora image shipping curl-minimal.
…check scripts/package/mkdebian lists python3:native in Build-Depends-Arch since Linux 6.13, so dpkg-checkbuilddeps aborts `make bindeb-pkg` on minimal Debian/Ubuntu images, which do not ship python3: dpkg-checkbuilddeps: error: unmet build dependencies: python3:native The Fedora/RHEL list already carries python3, so only the Debian/Ubuntu family was affected. Found by the latest-install job (7.2.11); the pinned jobs build 6.12.112 and cannot hit it. - kernel_installer.sh: add python3 to the Debian INSTALL_PKGS - README.md: keep the dependency list in sync (tests/test_readme_deps.sh)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #43.
Problem
Every install job in
.github/workflows/test-install.ymlbuilds 6.12.112, the defaultkernel_version/KERNEL_VERSIONfallback. A run without-kbuilds whatever kernel.org calls stable, and--longterm/--mainlinebuild something else again — so nothing in CI covered the kernels users actually get. That is how the FedoraBuildRequires: (elfutils-devel or libdw-devel)break (Linux 6.15+) stayed green for four days (#43).Change
New
latest-installjob (Fedora 44, Debian 13) that runs./kernel_installer.shwith no arguments, the way users run it, and:/boot/vmlinuz-*instead of assuming one,vmlinuz,configand initramfs the same way the pinned jobs do.It runs on a weekly
schedule(23 5 * * 1) and onworkflow_dispatch, and is skipped forpush/pull_request— PR checks stay reproducible and independent of kernel.org's current release.Two supporting changes:
installanddistro-detectionjobs are skipped on thescheduleevent; the weekly run covers current-stable installs only.${{ github.event_name }}, so the weekly run cannot cancel an in-flight main or PR run on the same ref.Verification
distro-detection,install,mainline,custom-config-smoke,latest-install.schedule/workflow_dispatch, so this PR's own check run does not execute it — it first runs on the next weekly cron or on a manual dispatch (I can dispatch it on this branch to prove the code path before merge, if you want it verified first).main.