ci: move chaos to linux-rolling-stable #2271
Merged
Conversation
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
For some reason chaos is failing with the latest sched_ext/for-next kernel, see https://github.com/sched-ext/scx/actions/runs/15892717558/job/44818708334?pr=2253 for an example. This is fully reproducible it seems and it's unclear why it's happening. As I don't have time to debug this at the minute, drop chaos to linux-rolling-stable (6.15.3 at the minute) where it does pass CI so we can deal with it later. Currently chaos is blocking the for-next import. Changes to the CI to enable this: - Add `metadata.scx.ci.kernel.default` to specify a different default kernel for pull requests when the usual default of `sched_ext/for-next` is inappropriate. - Add `metadata.scx.ci.kernel.allowlist` to specify an acceptable set of kernels when many are inappropriate. - Add similar `metadata.scx.ci.kernel.blocklist` to avoid testing on a kernel when it's known to fail. The new metadata is managed in each scheduler's Cargo.toml rather than having to change a central list in the CI spec and removes some edge cases. Most of this change was tested in #2246 but we can't land that yet due to vmlinux issues. Keep all the new behaviour, even though we don't need `allowlist` except for wd40. Test plan: - Ran `.github/include/list-integration-tests.py` with various kernels. It worked. - Checked the new `scx_chaos` entry on this PR. It selects the correct kernel in the "Load kernel" step.
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.
For some reason chaos is failing with the latest sched_ext/for-next kernel, see
https://github.com/sched-ext/scx/actions/runs/15892717558/job/44818708334?pr=2253 for an example. This is fully reproducible it seems and it's unclear why it's happening.
As I don't have time to debug this at the minute, drop chaos to linux-rolling-stable (6.15.3 at the minute) where it does pass CI so we can deal with it later. Currently chaos is blocking the for-next import.
Changes to the CI to enable this:
metadata.scx.ci.kernel.defaultto specify a different default kernel for pull requests when the usual default ofsched_ext/for-nextis inappropriate.metadata.scx.ci.kernel.allowlistto specify an acceptable set of kernels when many are inappropriate.metadata.scx.ci.kernel.blocklistto avoid testing on a kernel when it's known to fail.The new metadata is managed in each scheduler's Cargo.toml rather than having to change a central list in the CI spec and removes some edge cases.
Most of this change was tested in #2246 but we can't land that yet due to vmlinux issues. Keep all the new behaviour, even though we don't need
allowlistexcept for wd40.Test plan:
.github/include/list-integration-tests.pywith various kernels. It worked.scx_chaosentry on this PR. It selects the correct kernel in the "Load kernel" step.