Duplicate kernel builds

[nuclearcat]

We have a situation when many trees have normal builds, and "-build-only" builds.
Probably it was supposed to make trees to build only, but to not execute test on them, but feature never got complete.
I have to rather complete it (which i prefer), or drop -build-only kernels.
Reducing tests for trees who anyway doesnt check them probably good idea.

My suggestion, to complete this feature and reduce duplicate build definitions i can implement two options for trees:
build-only: true|falst
tests-whitelist: ["testname", "testname2"]

Example:
https://api.kernelci.org/viewer?search=parent%3D697d760ca1ae387ffbb7c801
This means we build kbuild-gcc-14-riscv, and kbuild-gcc-14-riscv-build-only, which are identical builds, but one has tests, and another is build-only.

Debug info from forecast:
Identical builds: Params {"arch": "arm", "compiler": "gcc-14", "cross_compile": "arm-linux-gnueabihf-", "defconfig": "multi_v7_defconfig"}: ['kbuild-gcc-14-arm', 'kbuild-gcc-14-arm-build-only'],Params {"arch": "arm64", "compiler": "gcc-14", "cross_compile": "aarch64-linux-gnu-", "defconfig": "defconfig", "fragments": ["lab-setup", "kselftest"]}: ['kbuild-gcc-14-arm64', 'kbuild-gcc-14-arm64-build-only'],Params {"arch": "i386", "compiler": "gcc-14", "defconfig": "i386_defconfig"}: ['kbuild-gcc-14-i386', 'kbuild-gcc-14-i386-build-only'],Params {"arch": "riscv", "compiler": "gcc-14", "cross_compile": "riscv64-linux-gnu-", "defconfig": "defconfig"}: ['kbuild-gcc-14-riscv', 'kbuild-gcc-14-riscv-build-only'],

[nuclearcat]

Example of config (suggestion):

  # kernelci-pipeline/config/trees/qcom.yaml
  build_configs:
    qcom_master:
      tree: qcom
      branch: 'master'
      testing_policy: build-only

    qcom_next:
      tree: qcom
      branch: 'next'
      testing_policy: all   # or omit if default is "all"

[bhcopeland]

+1 for this, this makes sense. Looking into this, it should eliminate a handful of duplicate builds. The testing_policy makes sense; it seems that specific trees use build-only-trees-rules, but regular jobs do not exclude them.

[broonie]

I agree, only thing that occurs to me is that we might want to allow the testing policy to be configurable per build rather than having a pre-cooked list but that's a bunch of complexity we don't actually need now and could always be added later (eg, "filter" and then have another key specifying the filter, or just look for filters first and fall back to the policies).

[minash-ti]

@nuclearcat I am not sure I understand the point of these duplicate builds. Why would we want to spend compute resources to execute exact same build twice -- even if one of them is marked as build-only and the other isn't? For example, what would be a reason for someone to look at this build:
https://dashboard.kernelci.org/build/maestro%3A6980dcfea1ae387ffbb99f0c?i=5&o=ti

instead of this one?
https://dashboard.kernelci.org/build/maestro%3A6980dd22a1ae387ffbb99f28?i=5&o=ti

and how would they find the difference between them anyway?

[nuclearcat]

@minash-ti original purpose was to make build-only builds (without tests), but seems implementation was incomplete and this is exactly what i am trying to solve, get rid duplicate builds and implement "build-only" policy properly.

[minash-ti]

ok @nuclearcat -- thanks! What would be valid values for testing_policy field -- is it just build-only and all?

[nuclearcat]

ok @nuclearcat -- thanks! What would be valid values for testing_policy field -- is it just build-only and all?

for now yes, we might extend it later if necessary (maybe boot-only, for example)

[minash-ti]

Thanks @nuclearcat , sounds good to me.