ci: test the shedulers with the latest sched-ext kernel #95
Conversation
.github/workflows/build-scheds.yml
Outdated
| - run: mkdir -p kernel | ||
| - run: for f in *.deb; do dpkg -x $f kernel; done | ||
| # Get the latest sched-ext enabled kernel directly from the git repository | ||
| - run: git clone https://github.com/sched-ext/sched_ext.git linux |
There was a problem hiding this comment.
The dev branch is sched_ext. One worry is that when we make breaking changes in the kernel, this would immediately break CI for scx repo. Would it be possible to make it try sched_ext-ci first and then if that's not present try sched_ext so that we have a way to lag a bit when necessary?
There was a problem hiding this comment.
Alternatively, we could have a release source tarball for CI that we get and untar here. That would also speed up CI as we wouldn't have to clone the entire repo.
There was a problem hiding this comment.
Then we could just go with git clone --single-branch -b sched-ext --depth 1 and it would be like fetching a tarball.
There was a problem hiding this comment.
...and git ls-remote or similar to check if sched-ext-ci or sched-ext exist.
arighi
force-pushed
the
github-ci
branch
3 times, most recently
from
6a4e197
to
9e866c4
Compare
Instead of downloading a precompiled sched-ext enabled kernel from the Ubuntu ppa, fetch the latest kernel directly from the sched-ext git repository and recompile it on-the-fly using virtme-ng. This allows to get rid of the Ubuntu ppa dependency, take out from the equation potential Ubuntu-specific patches, and ensures testing all the schedulers with the most up-to-date sched-ext kernel (that should also help to detect potential kernel-related issues in advance). The downside is that the CI runs will take a bit longer now, because we are recompiling the kernel from scratch. However, the kernel built with virtme-ng is relatively quick to compile and includes all the sched-ext features required for testing. It's worth noting that this method aligns with the current sched-ext kernel CI, where we test only the in-kernel schedulers (as intended). This change allows to extend the test coverage, using the same kernel to test also the schedulers included in this repository. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Instead of downloading a precompiled sched-ext enabled kernel from the Ubuntu ppa, fetch the latest kernel directly from the sched-ext git repository and recompile it on-the-fly using virtme-ng.
This allows to get rid of the Ubuntu ppa dependency, take out from the equation potential Ubuntu-specific patches, and ensures testing all the schedulers with the most up-to-date sched-ext kernel (that should also help to detect potential kernel-related issues in advance).
The downside is that the CI runs will take a bit longer now, because we are recompiling the kernel from scratch. However, the kernel built with virtme-ng is relatively quick to compile and includes all the sched-ext features required for testing.
It's worth noting that this method aligns with the current sched-ext kernel CI, where we test only the in-kernel schedulers (as intended).
This change allows to extend the test coverage, using the same kernel to test also the schedulers included in this repository.