W dniu 17.06.2011 18:24, Zach Pfeffer pisze:
One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page.
It is listed, unless I'm mistaken:
http://validation.linaro.org/launch-control/dashboard/test-results/399109/
See the "Android.URL" below.
Then I'd like to see a link from a android-build.linaro.org build like:
https://android-build.linaro.org/builds/~linaro-android/leb-panda/
This is a little bit more complex. Whatever submits the result can build an URL to the result page on the dashboard. The problem is that the android build system has no knowledge of tests.
Ideally each build would trigger a test to be scheduled, results of each test should be uploaded to the dashboard. This way we could retain identity in all participating components.
Thanks ZK
On 17 June 2011 11:45, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 17.06.2011 18:24, Zach Pfeffer pisze:
One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page.
It is listed, unless I'm mistaken:
http://validation.linaro.org/launch-control/dashboard/test-results/399109/
See the "Android.URL" below.
Hey cool. Now if I can search and see all the test runs.
Then I'd like to see a link from a android-build.linaro.org build like:
https://android-build.linaro.org/builds/~linaro-android/leb-panda/
This is a little bit more complex. Whatever submits the result can build an URL to the result page on the dashboard. The problem is that the android build system has no knowledge of tests.
Ideally each build would trigger a test to be scheduled, results of each test should be uploaded to the dashboard. This way we could retain identity in all participating components.
Yeah. Perhaps the android-build should just kick the test off. Is there a simple API to request this? Something like:
test(build_url, target, type)
...and if the target it busy, we just skip the test and provide a link on the android-build site that lets you re-request? I'll file a bp for this.
Thanks ZK
W dniu 17.06.2011 23:50, Zach Pfeffer pisze:
On 17 June 2011 11:45, Zygmunt Krynickizygmunt.krynicki@linaro.org wrote:
W dniu 17.06.2011 18:24, Zach Pfeffer pisze:
One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page.
It is listed, unless I'm mistaken:
http://validation.linaro.org/launch-control/dashboard/test-results/399109/
See the "Android.URL" below.
Hey cool. Now if I can search and see all the test runs.
I can make a report that will list all for you with links to test results. Let's do that on Monday.
Ideally each build would trigger a test to be scheduled, results of each test should be uploaded to the dashboard. This way we could retain identity in all participating components.
Yeah. Perhaps the android-build should just kick the test off. Is there a simple API to request this? Something like:
test(build_url, target, type)
Michael is working on the scheduler. He recently added API for submitting a job to the system. It's still some time before this can be used in production though. AFAIR there is no code that would take jobs and actually ask dispatchers to run them.
...and if the target it busy, we just skip the test and provide a link on the android-build site that lets you re-request? I'll file a bp for this.
The scheduler will queue jobs. Once a dispatcher is idle it will simply run another test.
Thanks ZK
On 18 June 2011 04:07, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 17.06.2011 23:50, Zach Pfeffer pisze:
On 17 June 2011 11:45, Zygmunt Krynickizygmunt.krynicki@linaro.org wrote:
W dniu 17.06.2011 18:24, Zach Pfeffer pisze:
One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page.
It is listed, unless I'm mistaken:
http://validation.linaro.org/launch-control/dashboard/test-results/399109/
See the "Android.URL" below.
Hey cool. Now if I can search and see all the test runs.
I can make a report that will list all for you with links to test results. Let's do that on Monday.
Cool. Thanks.
Ideally each build would trigger a test to be scheduled, results of each test should be uploaded to the dashboard. This way we could retain identity in all participating components.
Yeah. Perhaps the android-build should just kick the test off. Is there a simple API to request this? Something like:
test(build_url, target, type)
Michael is working on the scheduler. He recently added API for submitting a job to the system. It's still some time before this can be used in production though. AFAIR there is no code that would take jobs and actually ask dispatchers to run them.
Since we're got such low usage at the moment, is there any way we can start to use it without a full scheduler in place? For instance, Paul had mentioned that we could email him and he would kick off jobs. Perhaps we could just agree on times that android-build could request tests? Do a manual schedule?
...and if the target it busy, we just skip the test and provide a link on the android-build site that lets you re-request? I'll file a bp for this.
The scheduler will queue jobs. Once a dispatcher is idle it will simply run another test.
On Sat, 18 Jun 2011 04:31:24 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 18 June 2011 04:07, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Michael is working on the scheduler. He recently added API for submitting a job to the system. It's still some time before this can be used in production though. AFAIR there is no code that would take jobs and actually ask dispatchers to run them.
Since we're got such low usage at the moment, is there any way we can start to use it without a full scheduler in place? For instance, Paul had mentioned that we could email him and he would kick off jobs. Perhaps we could just agree on times that android-build could request tests? Do a manual schedule?
I have the guts of the scheduler written already. It doesn't really have a UI and the error reporting is terrible and it probably has bugs, but I think we should try to get this deployed ASAP and improve that rather than invest time in band-aid type solutions (as I said in the other email, I'll describe my progress later today).
Actually doing the deployment is probably the sticking point of this. I don't know much about the current set up we have, but AIUI we've kinda shuffled our code around a bit since the last one so some things probably need to change. I know Zygmunt has been working on tools to build all our code into a PPA, so if that's nearly ready, can we deploy lava-dispatcher in place of launch-control soon? Once that's done, adding the scheduler to the mix will be pretty easy (the benefit of all this shuffling).
Something I don't completely have a plan for in my head at the moment is connecting the dots, or preserving identity between componenets (as I think Zygmunt put it). We have a build, which will trigger a test run, which will result in a test bundle being uploaded to the dashboard. I can see how to link the build to the test run and (mostly -- I'd like to talk about the details of this) see how to link the test run to the bundle, but I don't quite see how to have a link on the build page that goes straight to the results. I guess we can always have a $job_url/results link that does a redirect to the appropriate page in the dashboard...
Cheers, mwh
Haha! Cool. I've got just the guy to help out. We've got a convert from ST Ericsson starting tomorrow and I think this'll be a perfect task for him to start with. Look for a contact from Frans Gifford. I'll CC you on my email to him. Would you create a BP named something like "connect the dots?"
-Zach
On 19 June 2011 19:10, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
On Sat, 18 Jun 2011 04:31:24 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 18 June 2011 04:07, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Michael is working on the scheduler. He recently added API for submitting a job to the system. It's still some time before this can be used in production though. AFAIR there is no code that would take jobs and actually ask dispatchers to run them.
Since we're got such low usage at the moment, is there any way we can start to use it without a full scheduler in place? For instance, Paul had mentioned that we could email him and he would kick off jobs. Perhaps we could just agree on times that android-build could request tests? Do a manual schedule?
I have the guts of the scheduler written already. It doesn't really have a UI and the error reporting is terrible and it probably has bugs, but I think we should try to get this deployed ASAP and improve that rather than invest time in band-aid type solutions (as I said in the other email, I'll describe my progress later today).
Actually doing the deployment is probably the sticking point of this. I don't know much about the current set up we have, but AIUI we've kinda shuffled our code around a bit since the last one so some things probably need to change. I know Zygmunt has been working on tools to build all our code into a PPA, so if that's nearly ready, can we deploy lava-dispatcher in place of launch-control soon? Once that's done, adding the scheduler to the mix will be pretty easy (the benefit of all this shuffling).
Something I don't completely have a plan for in my head at the moment is connecting the dots, or preserving identity between componenets (as I think Zygmunt put it). We have a build, which will trigger a test run, which will result in a test bundle being uploaded to the dashboard. I can see how to link the build to the test run and (mostly -- I'd like to talk about the details of this) see how to link the test run to the bundle, but I don't quite see how to have a link on the build page that goes straight to the results. I guess we can always have a $job_url/results link that does a redirect to the appropriate page in the dashboard...
Cheers, mwh
On Mon, 20 Jun 2011 12:10:08 +1200, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Something I don't completely have a plan for in my head at the moment is connecting the dots, or preserving identity between componenets (as I think Zygmunt put it). We have a build, which will trigger a test run, which will result in a test bundle being uploaded to the dashboard. I can see how to link the build to the test run and (mostly -- I'd like to talk about the details of this) see how to link the test run to the bundle, but I don't quite see how to have a link on the build page that goes straight to the results. I guess we can always have a $job_url/results link that does a redirect to the appropriate page in the dashboard...
I think it's vital for LAVA to connect a test run and the results from it, and I'm sure it will, but the details of that are something for you to decide.
As a consumer of LAVA though I think it's also vital that there is some way to link to a particular test run for things like android-build.linaro.org.
One way to do this would be to provide a test id back as the response to the API calls that schedule tests. That test id can then be used to contstruct URLs or make API calls.
If you don't want test ids to be the basis of APIs etc. then we could also make use of something that worked based on an externally defined identifier (e.g. the android-build.linaro.org URL.) If we could make API calls specifying our identifier, and maybe construct URLs too then we can also use that to display results or whatever on android-build.linaro.org.
In terms of implementation I think that the latter would be easier given where android-build.linaro.org is now, but I don't think the former would be that much harder for us to do.
As for android-build.linaro.org building other things I don't think that's really an issue for LAVA, as I think that we should push from android-build.linaro.org to LAVA, rather than having LAVA pull. android-build.linaro.org can then decide based on the build type what info to submit, including the type of artifacts, and LAVA can have a simpler job to map from say "android" to the set of tests to run for that.
Thanks,
James
On 20 June 2011 08:29, James Westby james.westby@canonical.com wrote:
On Mon, 20 Jun 2011 12:10:08 +1200, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Something I don't completely have a plan for in my head at the moment is connecting the dots, or preserving identity between componenets (as I think Zygmunt put it). We have a build, which will trigger a test run, which will result in a test bundle being uploaded to the dashboard. I can see how to link the build to the test run and (mostly -- I'd like to talk about the details of this) see how to link the test run to the bundle, but I don't quite see how to have a link on the build page that goes straight to the results. I guess we can always have a $job_url/results link that does a redirect to the appropriate page in the dashboard...
I think it's vital for LAVA to connect a test run and the results from it, and I'm sure it will, but the details of that are something for you to decide.
As a consumer of LAVA though I think it's also vital that there is some way to link to a particular test run for things like android-build.linaro.org.
One way to do this would be to provide a test id back as the response to the API calls that schedule tests. That test id can then be used to contstruct URLs or make API calls.
If you don't want test ids to be the basis of APIs etc. then we could also make use of something that worked based on an externally defined identifier (e.g. the android-build.linaro.org URL.) If we could make API calls specifying our identifier, and maybe construct URLs too then we can also use that to display results or whatever on android-build.linaro.org.
Lets cut out one level of indirection and use the build URL as the id.
In terms of implementation I think that the latter would be easier given where android-build.linaro.org is now, but I don't think the former would be that much harder for us to do.
As for android-build.linaro.org building other things I don't think that's really an issue for LAVA, as I think that we should push from android-build.linaro.org to LAVA, rather than having LAVA pull. android-build.linaro.org can then decide based on the build type what info to submit, including the type of artifacts, and LAVA can have a simpler job to map from say "android" to the set of tests to run for that.
Yeah, I agree that LAVA shouldn't pull anything. The build system should be requesting the tests at a high level, i.e. please run the "Android Benchmark and Test load on build x."
The build should also probably wait until the test is done and get a pass fail, this should help set us up for Gerrit integration in the near future.
I'll pull a BP together.
Thanks,
James
On Mon, 20 Jun 2011 09:35:00 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 20 June 2011 08:29, James Westby james.westby@canonical.com wrote:
On Mon, 20 Jun 2011 12:10:08 +1200, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Something I don't completely have a plan for in my head at the moment is connecting the dots, or preserving identity between componenets (as I think Zygmunt put it). We have a build, which will trigger a test run, which will result in a test bundle being uploaded to the dashboard. I can see how to link the build to the test run and (mostly -- I'd like to talk about the details of this) see how to link the test run to the bundle, but I don't quite see how to have a link on the build page that goes straight to the results. I guess we can always have a $job_url/results link that does a redirect to the appropriate page in the dashboard...
I think it's vital for LAVA to connect a test run and the results from it, and I'm sure it will, but the details of that are something for you to decide.
As a consumer of LAVA though I think it's also vital that there is some way to link to a particular test run for things like android-build.linaro.org.
Clearly.
One way to do this would be to provide a test id back as the response to the API calls that schedule tests. That test id can then be used to contstruct URLs or make API calls.
Yes, that sounds fine.
If you don't want test ids to be the basis of APIs etc. then we could also make use of something that worked based on an externally defined identifier (e.g. the android-build.linaro.org URL.) If we could make API calls specifying our identifier, and maybe construct URLs too then we can also use that to display results or whatever on android-build.linaro.org.
Lets cut out one level of indirection and use the build URL as the id.
Is this expressing a preference or just trying to be helpful by getting some decisions made? Because in general I would rather those doing the implementation being the ones to make the implementation decisions. And requirements are best expressed using the "as a ... i want to ... so that i can ..." template.
(apologies if this sounds snarky)
Is being able to externally specify the job/test identifier a requirement?
In terms of implementation I think that the latter would be easier given where android-build.linaro.org is now, but I don't think the former would be that much harder for us to do.
As for android-build.linaro.org building other things I don't think that's really an issue for LAVA, as I think that we should push from android-build.linaro.org to LAVA, rather than having LAVA pull. android-build.linaro.org can then decide based on the build type what info to submit, including the type of artifacts, and LAVA can have a simpler job to map from say "android" to the set of tests to run for that.
Yeah, I agree that LAVA shouldn't pull anything. The build system should be requesting the tests at a high level, i.e. please run the "Android Benchmark and Test load on build x."
Cool.
The build should also probably wait until the test is done and get a pass fail, this should help set us up for Gerrit integration in the near future.
I guess the naive implementation of this would leave the EC2 instance running while the test runs which would be wasteful... but that's something for Paul to figure out.
I'll pull a BP together.
Cool. I don't *think* this is covered by an existing blueprint...
Cheers, mwh
Frans is going to work to pull these together. There's a BP at:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-connect...
-Zach
On 20 June 2011 18:47, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
On Mon, 20 Jun 2011 09:35:00 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 20 June 2011 08:29, James Westby james.westby@canonical.com wrote:
On Mon, 20 Jun 2011 12:10:08 +1200, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Something I don't completely have a plan for in my head at the moment is connecting the dots, or preserving identity between componenets (as I think Zygmunt put it). We have a build, which will trigger a test run, which will result in a test bundle being uploaded to the dashboard. I can see how to link the build to the test run and (mostly -- I'd like to talk about the details of this) see how to link the test run to the bundle, but I don't quite see how to have a link on the build page that goes straight to the results. I guess we can always have a $job_url/results link that does a redirect to the appropriate page in the dashboard...
I think it's vital for LAVA to connect a test run and the results from it, and I'm sure it will, but the details of that are something for you to decide.
As a consumer of LAVA though I think it's also vital that there is some way to link to a particular test run for things like android-build.linaro.org.
Clearly.
One way to do this would be to provide a test id back as the response to the API calls that schedule tests. That test id can then be used to contstruct URLs or make API calls.
Yes, that sounds fine.
If you don't want test ids to be the basis of APIs etc. then we could also make use of something that worked based on an externally defined identifier (e.g. the android-build.linaro.org URL.) If we could make API calls specifying our identifier, and maybe construct URLs too then we can also use that to display results or whatever on android-build.linaro.org.
Lets cut out one level of indirection and use the build URL as the id.
Is this expressing a preference or just trying to be helpful by getting some decisions made? Because in general I would rather those doing the implementation being the ones to make the implementation decisions. And requirements are best expressed using the "as a ... i want to ... so that i can ..." template.
(apologies if this sounds snarky)
Is being able to externally specify the job/test identifier a requirement?
In terms of implementation I think that the latter would be easier given where android-build.linaro.org is now, but I don't think the former would be that much harder for us to do.
As for android-build.linaro.org building other things I don't think that's really an issue for LAVA, as I think that we should push from android-build.linaro.org to LAVA, rather than having LAVA pull. android-build.linaro.org can then decide based on the build type what info to submit, including the type of artifacts, and LAVA can have a simpler job to map from say "android" to the set of tests to run for that.
Yeah, I agree that LAVA shouldn't pull anything. The build system should be requesting the tests at a high level, i.e. please run the "Android Benchmark and Test load on build x."
Cool.
The build should also probably wait until the test is done and get a pass fail, this should help set us up for Gerrit integration in the near future.
I guess the naive implementation of this would leave the EC2 instance running while the test runs which would be wasteful... but that's something for Paul to figure out.
I'll pull a BP together.
Cool. I don't *think* this is covered by an existing blueprint...
Cheers, mwh
On Mon, Jun 20, 2011 at 9:35 PM, Zach Pfeffer zach.pfeffer@linaro.orgwrote:
Frans is going to work to pull these together. There's a BP at:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-connect...
-Zach
On 20 June 2011 18:47, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
The build should also probably wait until the test is done and get a pass fail, this should help set us up for Gerrit integration in the near future.
I guess the naive implementation of this would leave the EC2 instance running while the test runs which would be wasteful... but that's something for Paul to figure out.
Would that really be necessary? Or does the process go more like: 1. topic branch created with testing requested, intended for inclusion if everything is ok 2. do testing 3. if tests pass, merge (is this manual?)
The blueprint mentioned doesn't seem to cover the reverse path for Gerrit to somehow interpret those test results and do something with them. Should it? If so, I think we need to better understand how that piece works from the Gerrit side.
Thanks, Paul Larson
On 21 June 2011 14:10, Paul Larson paul.larson@linaro.org wrote:
On Mon, Jun 20, 2011 at 9:35 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Frans is going to work to pull these together. There's a BP at:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-connect...
-Zach
On 20 June 2011 18:47, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
The build should also probably wait until the test is done and get a pass fail, this should help set us up for Gerrit integration in the near future.
I guess the naive implementation of this would leave the EC2 instance running while the test runs which would be wasteful... but that's something for Paul to figure out.
Would that really be necessary? Or does the process go more like:
- topic branch created with testing requested, intended for inclusion if
everything is ok 2. do testing 3. if tests pass, merge (is this manual?)
Yeah. That sync's up with the Gerrit flow: http://source.android.com/source/life-of-a-patch.html
The blueprint mentioned doesn't seem to cover the reverse path for Gerrit to somehow interpret those test results and do something with them. Should it? If so, I think we need to better understand how that piece works from the Gerrit side.
Lets mumble about this.
Thanks, Paul Larson
On Tue, 21 Jun 2011 11:47:04 +1200, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Is being able to externally specify the job/test identifier a requirement?
Not from the build service's point of view.
It makes it easier right now as currently there isn't somewhere for us to store the LAVA id we would get back for a particular job. I don't think we'll go for very long without having somewhere to store that data, so it's not a blocker.
As a general principle though it is a bit easier for clients if they can specify an id, but it does have an impact on data integrity, indexing etc., so I think it's your call as to what LAVA supports.
Thanks,
James
On Sat, 18 Jun 2011 11:07:32 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 17.06.2011 23:50, Zach Pfeffer pisze:
On 17 June 2011 11:45, Zygmunt Krynickizygmunt.krynicki@linaro.org wrote:
Ideally each build would trigger a test to be scheduled, results of each test should be uploaded to the dashboard. This way we could retain identity in all participating components.
Yeah. Perhaps the android-build should just kick the test off. Is there a simple API to request this? Something like:
test(build_url, target, type)
Michael is working on the scheduler. He recently added API for submitting a job to the system.
Right. It's not quite "test(build_url, target, type)" but that sort of interface can be built on top.
It's still some time before this can be used in production though. AFAIR there is no code that would take jobs and actually ask dispatchers to run them.
There is! I just haven't told anyone about it yet, because it got written on Friday afternoon. Look for a mail from me about this later today.
...and if the target it busy, we just skip the test and provide a link on the android-build site that lets you re-request? I'll file a bp for this.
The scheduler will queue jobs. Once a dispatcher is idle it will simply run another test.
Right.
Cheers, mwh
W dniu 18.06.2011 11:07, Zygmunt Krynicki pisze:
One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page.
It is listed, unless I'm mistaken:
http://validation.linaro.org/launch-control/dashboard/test-results/399109/
See the "Android.URL" below.
Hey cool. Now if I can search and see all the test runs.
I can make a report that will list all for you with links to test results. Let's do that on Monday.
Hi, this was a very simple report, have a look.
It shows the 10 most recent test runs of anything that has "android.url" attribute.
http://validation.linaro.org/launch-control/dashboard/reports/android-runs/
Best regards ZK
Hello Zygmunt,
On Mon, 20 Jun 2011 10:00:10 +0200 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 18.06.2011 11:07, Zygmunt Krynicki pisze:
One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page.
It is listed, unless I'm mistaken:
http://validation.linaro.org/launch-control/dashboard/test-results/399109/
See the "Android.URL" below.
Hey cool. Now if I can search and see all the test runs.
I can make a report that will list all for you with links to test results. Let's do that on Monday.
Hi, this was a very simple report, have a look.
It shows the 10 most recent test runs of anything that has "android.url" attribute.
http://validation.linaro.org/launch-control/dashboard/reports/android-runs/
Just to remind, at https://android-build.linaro.org , there can be other build types besides "Android platform", e.g. "Android toolchain": https://android-build.linaro.org/jenkins/job/pfalcon_linaro-toolchain/
I remember that at LDS I heard that you guys have input artifact classifier on the entry to Lava, so I hope you use it to differentiate among the builds. If you need any info for that from Android build system, let's discuss it.
Best regards ZK
W dniu 20.06.2011 10:50, Paul Sokolovsky pisze:
Hi, this was a very simple report, have a look.
It shows the 10 most recent test runs of anything that has "android.url" attribute.
http://validation.linaro.org/launch-control/dashboard/reports/android-runs/
Just to remind, at https://android-build.linaro.org , there can be other build types besides "Android platform", e.g. "Android toolchain": https://android-build.linaro.org/jenkins/job/pfalcon_linaro-toolchain/
Err. I don't quite understand. Does it mean that android-build.linaro.org can build things other than android itself?
I remember that at LDS I heard that you guys have input artifact classifier on the entry to Lava, so I hope you use it to differentiate among the builds. If you need any info for that from Android build system, let's discuss it.
I have no knowledge of that. I currently list all TestRuns that have a custom attribute called 'android.url'.
Have a look:
http://bazaar.launchpad.net/~linaro-validation/lava-dashboard/data-views-and...
Can you tell me if I should do some kind of filtering/processing?
Thanks for letting me know about this ZK
On Mon, 20 Jun 2011 10:56:16 +0200 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 20.06.2011 10:50, Paul Sokolovsky pisze:
Hi, this was a very simple report, have a look.
It shows the 10 most recent test runs of anything that has "android.url" attribute.
http://validation.linaro.org/launch-control/dashboard/reports/android-runs/
Just to remind, at https://android-build.linaro.org , there can be other build types besides "Android platform", e.g. "Android toolchain": https://android-build.linaro.org/jenkins/job/pfalcon_linaro-toolchain/
Err. I don't quite understand. Does it mean that android-build.linaro.org can build things other than android itself?
Yes, it's "Cloud Buildd", the generic build service, and so far builds two artifact types: "Android platform" (images you can run on a device) and "Android toolchain" (Linaro toolchain configured to build Android platform).
I remember that at LDS I heard that you guys have input artifact classifier on the entry to Lava, so I hope you use it to differentiate among the builds. If you need any info for that from Android build system, let's discuss it.
I have no knowledge of that. I currently list all TestRuns that have a custom attribute called 'android.url'.
Have a look:
http://bazaar.launchpad.net/~linaro-validation/lava-dashboard/data-views-and...
Can you tell me if I should do some kind of filtering/processing?
Yes, apparently. Can you point me to the code which queues and sets 'android.url' attribute on a test input?
Thanks for letting me know about this ZK
W dniu 20.06.2011 11:20, Paul Sokolovsky pisze:
Have a look:
http://bazaar.launchpad.net/~linaro-validation/lava-dashboard/data-views-and...
Can you tell me if I should do some kind of filtering/processing?
Yes, apparently. Can you point me to the code which queues and sets 'android.url' attribute on a test input?
I have no idea how that works. Paul Larson is the person to ask I think.
It could be in the dispatcher code or in some local configuration for the dispatcher on validation.linaro.org.
Thanks ZK
On Mon, Jun 20, 2011 at 4:20 AM, Paul Sokolovsky <paul.sokolovsky@linaro.org
wrote:
Can you tell me if I should do some kind of filtering/processing?
Yes, apparently. Can you point me to the code which queues and sets 'android.url' attribute on a test input?
It's a script that I'm just hacking together as a temporary solution while
we have to poll. You can either point it at a url of the type Zach wanted, or point it at the build name and build id and it will find the necessary pieces. At this point, it would probably just choke if you pointed it at a toolchain build. If it didn't, lava would because it doesn't have any way to deal with toolchain artifacts at the moment. So, for right now it's safe to assume that any results we have are for android, not for a android-build built toolchain.
The reason for pointing at the url in the metadata, was because that's how Zach said he wanted to search for results.
Thanks, Paul Larson
-
James Westby -
Michael Hudson-Doyle -
Paul Larson -
Paul Sokolovsky -
Zach Pfeffer -
Zygmunt Krynicki