On Mon, Sep 24, 2012 at 2:13 AM, Michael Hudson-Doyle <[email protected]> wrote: > Fathi Boudra <[email protected]> writes: > >> 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. > > And how is that working out? I guess there is no android-build results > dashboard thing for those jobs yet.
For android-build it would be just a matter of remembering all submitted job ids and then fixing UI to display all results in TABs or in a single table with new columns for each board. Initially just stacking one table each would also work :) -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
