-
Notifications
You must be signed in to change notification settings - Fork 10
Initial matrix reduction #831
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
nathanchance
merged 11 commits into
ClangBuiltLinux:main
from
nathanchance:reduce-build-coverage
May 4, 2025
Merged
Initial matrix reduction #831
nathanchance
merged 11 commits into
ClangBuiltLinux:main
from
nathanchance:reduce-build-coverage
May 4, 2025
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
Initially, this tree was added to try and catch arm64 specific regressions and stand out from -next. Ultimately, it has not proved more useful than just testing -next directly because there have rarely been regressions from this tree and it requires additional effort to patch mainline regressions. This reduces the number of weekly builds by 430. Signed-off-by: Nathan Chancellor <[email protected]>
While there are not many builds per week (180) for these trees, they have become broken for lengthy periods of time before and most issues come from downstream vendor code, not upstream Linux, which is harder to fix through Gerrit or report to the ChromeOS issue tracker. Signed-off-by: Nathan Chancellor <[email protected]>
These trees still use a version of clang 12 so it is unlikely that they will see a compiler upgrade at this point because it could affect the KMI, so there is little point in testing them with new versions of clang. This reduces the number of builds per week by 368. Signed-off-by: Nathan Chancellor <[email protected]>
Currently, android14-{5.15,6.1} use LLVM 17, android15-6.6 uses LLVM 18,
and android-mainline uses LLVM 19, so there is no point in testing with
versions of LLVM older than those because they will never be used. This
reduces the number of weekly builds by 165.
Signed-off-by: Nathan Chancellor <[email protected]>
Halve the number of builds done with LLVM tip of tree and the latest stable LLVM version per week, as it should not result in too much delay in finding issues and at this point, a good amount of breakage coming out of mainline directly (as opposed to coming from -next) is not actually clang related. This saves 790 builds per week. Signed-off-by: Nathan Chancellor <[email protected]>
I missed these in 3d9c49a ("generator: yml: Drop x86 builds with LLVM 13 and 14 on -next and tip"). Signed-off-by: Nathan Chancellor <[email protected]>
To start reducing the matrix frequency, add a set of anchors for builds that only happen on Tuesday and Thursday. Signed-off-by: Nathan Chancellor <[email protected]>
… LLVM versions In general, we want to keep older versions of LLVM versions working but we do not need to run builds against these trees every day, as it is becoming more and more rare to experience a particular problem in an older version of LLVM but not a newer one (unless we missed adding a workaround). -next frequency is kept daily to continue to try and catch problems. This saves about 790 builds a week. Signed-off-by: Nathan Chancellor <[email protected]>
While this only saves around 100 builds, it should not really make that much of a difference for finding and reporting problems because these trees do not move very quickly and are covered by KernelCI as well. Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
kees
approved these changes
May 3, 2025
Contributor
kees
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a lot of builds saved per week! Nice work. This looks good to me.
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.
See the individual commits for more details but at a high level, this pull request aims to try and reduce the number of builds we are doing due to potential resource constraints, while not taking a massive hit in the actual results of CI. Namely, it eliminates several trees that are low value or have alternatives for coverage, reduces builds done with older toolchains, and reduces the mainline build frequency. All in all, this kills about 20% of the matrix.