Hi,
We currently do a few builds in Linaro that can boot on a whole set of device_types.
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.
Thoughts? Other ideas?
Hi Alexander,
We're planning a Connect session on just this topic. :)
Dave
On 20 Sep 2012, at 09:44, Alexander Sack wrote:
Hi,
We currently do a few builds in Linaro that can boot on a whole set of device_types.
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.
Thoughts? Other ideas?
-- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On Thu, Sep 20, 2012 at 11:05 AM, Dave Pigott dave.pigott@linaro.org wrote:
Hi Alexander,
We're planning a Connect session on just this topic. :)
Telepathy! :) very good.
Will we go with concrete options to discuss into that session? What's the current way of thinking?
Dave
On 20 Sep 2012, at 09:44, Alexander Sack wrote:
Hi,
We currently do a few builds in Linaro that can boot on a whole set of device_types.
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.
Thoughts? Other ideas?
-- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On 20 Sep 2012, at 11:14, Alexander Sack wrote:
On Thu, Sep 20, 2012 at 11:05 AM, Dave Pigott dave.pigott@linaro.org wrote:
Hi Alexander,
We're planning a Connect session on just this topic. :)
Telepathy! :) very good.
Will we go with concrete options to discuss into that session? What's the current way of thinking?
So far, the extent of it is me suggesting it as a session, then Andy suggesting the discussion centres around how we support it, and how can services like Android use it, and Michael commenting that it is easy enough to see how one job file could be multiplied out, but less easy to see how we keep the data tied together well enough for lava clients to display the results sensibly.
Dave
On 09/20/2012 05:14 AM, Alexander Sack wrote:
On Thu, Sep 20, 2012 at 11:05 AM, Dave Pigott dave.pigott@linaro.org wrote:
Hi Alexander,
We're planning a Connect session on just this topic. :)
Telepathy! :) very good.
Will we go with concrete options to discuss into that session? What's the current way of thinking?
I think we'll have concrete ideas going in. I see two challenges on this topic:
1) the lava plumbing - this is probably not too hard 2) the "build front-ends" - ie android-build/daily-prebuilts (and new ones to come)
Item 2 may take up the most time and coordination. These front-ends will need updates to their job-submission logic as well as how they render their UI's.
Dave
On 20 Sep 2012, at 09:44, Alexander Sack wrote:
Hi,
We currently do a few builds in Linaro that can boot on a whole set of device_types.
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.
Thoughts? Other ideas?
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
On 21 September 2012 00:29, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
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).
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
Fathi Boudra fathi.boudra@linaro.org writes:
On 21 September 2012 00:29, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
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).
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.
Cheers, mwh
On Mon, Sep 24, 2012 at 2:13 AM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Fathi Boudra fathi.boudra@linaro.org writes:
On 21 September 2012 00:29, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
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).
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 :)
linaro-validation@lists.linaro.org
-
Alexander Sack -
Andy Doan -
Dave Pigott -
Fathi Boudra -
Michael Hudson-Doyle