Alexander Sack asac@linaro.org writes:
Hi,
We currently do a few builds in Linaro that can boot on a whole set of device_types.
Yeah.
Example: vexpress android can be build only once, but run in LAVA on vexpress-a9, -15, -TC2 and fastmodel XX,YY,ZZ, etc.
Unfortunately, we don't really support that use case very well in our CI so we end up submitting the artifact of a build to only one device_type automatically.
One approach to that problem would be to grow a feature in the scheduler to accept jobs that have a list of device_types in the job description.
So, what do we actually want to happen? We go to a page like this:
https://android-build.linaro.org/builds/~linaro-android/vexpress-jb-gcc47-ar...
and somehow see results for testing the build on -a9, -a15 and -tc2?
Just repeating the existing table three times doesn't really seem like a good option (it's already pretty unwieldy thanks to the way monkeyrunner tests are displayed) but let's assume this UI problem can be solved somehow.
Basically, we need to break the 1<->1 association between "jenkins build" and "dispatcher execution". One way would be to split this inside the dispatcher, so we would split the testjob table in some sense into testjob_submission and testjob_execution or something like that and define an API that operates on testjob_submission ids to return the results of all the related executions.
The split could also all be done client side, where the jenkins build just calls submit-job multiple times and stores a list of job ids instead of a single one in the lava-job-info artifact (or we could modify the submit-job CLI to do this for you, not much difference really).
Doing this in LAVA feels like it's probably "the right thing (tm)" but I'm not sure how we'd manage it in the UI. Doing it in the build scripts would probably be quicker and easier, but uglier and less reusable for any other projects that end up wanting the same sort of thing. If we want different tests to run on the different devices, then we really should do it client side.
The android-build js changes would be comparable for both approaches I think.
Cheers, mwh