On 21 September 2012 00:29, Michael Hudson-Doyle <[email protected]> wrote: > Alexander Sack <[email protected]> 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-armlt-tracking-open/#build=45 > > 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).
We already do that for PandaBoard pre-built image job, where we submit for panda and panda-es device types. > 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 _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
