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

stable-rc tests with cros:// fragments #759

Open
nuclearcat opened this issue Aug 19, 2024 · 4 comments
Open

stable-rc tests with cros:// fragments #759

nuclearcat opened this issue Aug 19, 2024 · 4 comments
Assignees

Comments

@nuclearcat
Copy link
Member

I noticed in stable-rc report following builds:
x86_64:(x86_64_defconfig + cros://chromeos-6.6/x86_64/chromeos-amd-stoneyridge.flavour.config)
which belongs to ChromiumOS and might not work properly with ordinary tests (as might miss NFS and other configuration parameters).
I think we need to make sure to not enable ordinary tests on such builds

Example report:
Subject: KernelCI report for stable-rc: v6.10.5-26-ga391301088d2
Date: Sun, 18 Aug 2024 07:50:02 -0700 (PDT) (08/18/2024 05:50:02 PM)

@nuclearcat
Copy link
Member Author

Sorry for not explaining well, i was writing this in rush. Problem is following:
We have tast tests running under OS: ChromeOS, which can run only with kernels built with cros:// fragments.
We have all other kind of tests (boot tests based on buildroot and others based on debos), that can run with different kernel configurations, but NOT cros:// fragments.
Right now we have problem, that boot tests are being executed on kernels built with cros:// fragments. We need to make sure kernels with cros:// fragments are used for ChromeOS tast tests only.

@JenySadadia
Copy link
Collaborator

Thank you for explaining in detail @nuclearcat
We would appreciate your insights on this @a-wai

@nuclearcat
Copy link
Member Author

yes, advice of Rules Magician urgently needed, and only one i know is @a-wai :-D this is why i added in issue

@a-wai
Copy link
Contributor

a-wai commented Aug 20, 2024

Which tests are you talking about exactly, baseline-*? If that's so, just drop the corresponding entries from scheduler-chromeos.yaml (those jobs are scheduled for kbuild-gcc-12-<arch>-chromeos-<flavour> kbuilds, only those should have cros://-based defconfigs).

If you actually need to add rules to some specific jobs, I'd say the following should work:

    rules:
      defconfig:
        - '!cros://chromeos-5.4/arm64/chromiumos-mediatek.flavour.config'
        - '!cros://chromeos-5.4/arm64/chromiumos-qualcomm.flavour.config'
        - '!cros://chromeos-5.4/x86_64/chromeos-amd-stoneyridge.flavour.config'
        - '!cros://chromeos-5.4/x86_64/chromeos-intel-pineview.flavour.config'
        - '!cros://chromeos-5.10/arm64/chromiumos-mediatek.flavour.config'
        - '!cros://chromeos-5.10/arm64/chromiumos-qualcomm.flavour.config'
        - '!cros://chromeos-5.10/x86_64/chromeos-amd-stoneyridge.flavour.config'
        - '!cros://chromeos-5.10/x86_64/chromeos-intel-pineview.flavour.config'
        - '!cros://chromeos-5.15/arm64/chromiumos-mediatek.flavour.config'
        - '!cros://chromeos-5.15/arm64/chromiumos-qualcomm.flavour.config'
        - '!cros://chromeos-5.15/x86_64/chromeos-amd-stoneyridge.flavour.config'
        - '!cros://chromeos-5.15/x86_64/chromeos-intel-pineview.flavour.config'
        - '!cros://chromeos-6.1/arm64/chromiumos-mediatek.flavour.config'
        - '!cros://chromeos-6.1/arm64/chromiumos-qualcomm.flavour.config'
        - '!cros://chromeos-6.1/x86_64/chromeos-amd-stoneyridge.flavour.config'
        - '!cros://chromeos-6.1/x86_64/chromeos-intel-pineview.flavour.config'
        - '!cros://chromeos-6.6/arm64/chromiumos-mediatek.flavour.config'
        - '!cros://chromeos-6.6/arm64/chromiumos-qualcomm.flavour.config'
        - '!cros://chromeos-6.6/x86_64/chromeos-amd-stoneyridge.flavour.config'
        - '!cros://chromeos-6.6/x86_64/chromeos-intel-pineview.flavour.config'

That's a bit long however, adding globbing support to the function parsing rules would be better so a simple !cros://* entry would be enough.

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

No branches or pull requests

4 participants