config/runtime: Add support for parameter "platforms"

[nuclearcat]

We might have limited set of platforms available in certain lab. Lab owners should have option to define such list.
As per suggestion: kernelci/kernelci-project#350 (comment)

[a-wai]

What would be the point of this, as in, what problem would it actually solve ? Scheduler entries already link to a runtime instance and list the platforms on which jobs should run.

I'm not sure adding platforms to runtime definitions would add anything useful here.

[nuclearcat]

We might have for example raspberry pi device defined as platform, available in baylibre and collabora, as many other common SBC, and we have job that will execute for example generic arm64 build on number of platforms and labs:

  - job: baseline-arm64
    event:
      channel: node
      name: kbuild-gcc-10-arm64
      result: pass
    runtime:
      type: lava
      name: lava-collabora
    platforms:
      - bcm2711-rpi-4-b
      - meson-g12b-a311d-khadas-vim3
      - rk3399-gru-kevin
      - rk3399-rock-pi-4b
      - rk3588-rock-5b
      - sun50i-h6-pine-h64

(we nee to add support of list of runtime names btw)
But for example baylibre don't want to allow KernelCI to run jobs on their Raspberry PI, so with this patch they can define list of allowed platforms only.

[nuclearcat]

Also this is easy and safe place (less error-prone) where lab owners can specify mandatory "permit" list, so nobody by mistake put jobs on devices that kernelci not supposed to run.

[a-wai]

TBH unless we add the ability to specify a runtime list in scheduler entries (which in itself sounds like a good idea) I doubt this will help: this adds yet another config possibility and might actually confuse new users, rather than help them.

Another possible use for this would be to provide a way to run a job on all platforms present in a given runtime/lab, but this would only work if a lab contains devices of only one architecture (as jobs depend on kbuild nodes, each providing a kernel for a single architecture).

My conclusion is that in the current state of things, adding one more parameter will only introduce more complexity and not solve any problem we can't already address with the way scheduler entries work.

If we were to change the scheduling logic (allow list of runtimes, run on all platforms of a given runtime if no platforms list, etc...) my opinion could change, but I think such changes should be discussed as a separate issue first.

[nuclearcat]

As per feedback closing for now