Skip to content
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

config: pipeline: Limit target trees/branches for Chromebook tests #962

Merged

Conversation

laura-nao
Copy link
Contributor

Currently, most tests on Chromebooks run across all available tree/branch combinations. Restrict these tests to stable-rc and mainline trees to simplify monitoring while still identifying relevant regressions.

@laura-nao laura-nao added the staging-skip Don't test automatically on staging.kernelci.org label Jan 8, 2025
@laura-nao laura-nao force-pushed the limit-chromebook-test-tree-branches branch 2 times, most recently from e4e88c2 to 387e694 Compare January 8, 2025 16:41
Baseline tests for Chromebooks may have different requirements regarding
tree/branch combinations and other parameters compared to baseline tests
on other platforms. To clarify this distinction, add a -chromebook
suffix to the relevant test job definitions.

Signed-off-by: Laura Nao <[email protected]>
Currently, most tests on Chromebooks run across all available
tree/branch combinations. Restrict these tests to stable-rc and mainline
trees to simplify monitoring while still identifying relevant
regressions.

Signed-off-by: Laura Nao <[email protected]>
@laura-nao
Copy link
Contributor Author

@nuclearcat @pawiecz feel free to drop the staging-skip label once you've had a chance to review and confirm the changes look good. Thanks!

Copy link
Contributor

@pawiecz pawiecz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, let's drop skip-staging and give it a test run before it can be deployed in prod

@pawiecz pawiecz removed the staging-skip Don't test automatically on staging.kernelci.org label Jan 10, 2025
@laura-nao
Copy link
Contributor Author

LGTM, let's drop skip-staging and give it a test run before it can be deployed in prod

Thanks! I checked the results on staging - I see results on mainline/master, e.g.:

And I don't see results on the kernelci tree anymore, e.g.:

So I guess this worked as expected. Now that I saw the results on staging, I wonder if we should keep running the tests on the kernelci tree as well though? otherwise they will just be available on the mainline tree on staging. Any thought on this @pawiecz @nuclearcat ?

@pawiecz
Copy link
Contributor

pawiecz commented Jan 13, 2025

So I guess this worked as expected.

👍

Now that I saw the results on staging, I wonder if we should keep running the tests on the kernelci tree as well though? otherwise they will just be available on the mainline tree on staging. Any thought on this @pawiecz @nuclearcat ?

Current default behavior on staging is to run tests from kernelci/* trees only. Linked test runs on mainline/master were triggered by @nuclearcat manually.

If you'd like to make Chromebook tests passing one of the Maestro PRs merge criteria then kernelci tree should be added to the triggering rules.

If you're confident about these test suites' stability and don't plan on changing them soon - filtering only mainline + stable-rc triggers should be fine (but it will require manual trigger on staging, if needed).

@nuclearcat
Copy link
Member

Usually if something might affect non-kernelci tree tests i trigger that tree manually, so it is not necessary to add tests to kernelci tree.

@laura-nao
Copy link
Contributor Author

Ack, sounds good and should be ready to merge then. Thanks both for the feedback!

@nuclearcat nuclearcat added this pull request to the merge queue Jan 13, 2025
Merged via the queue into kernelci:main with commit e8b6fb5 Jan 13, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants