Do you have a way we can dump the date and time of every build that we've done?
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
2012/1/14 Zygmunt Krynicki zygmunt.krynicki@linaro.org:
Data from all the builds with from-device timestamp (from revision 15 of my script):
http://paste.ubuntu.com/804677/
Note: currently lava has no way to harvest build date or additional build meta-data. If you know of a way just ping me.
2012/1/15 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 14 January 2012 16:34, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Also, I see one critical piece missing that was requested - the
datestamp.
I know, we simply don't have any. The best that I can do is give you the submission timestamp.
That would be good (in the worst case I'd just check the build time of the build that was tested).
Bero, does this give you enough to go on for now? I requested staging-panda as an initial data set since it seems to be the most complete. The board type used is probably not important to mention in the graph anyway.
I can generate the data for any (all?) builds.
Please do, we want it to show something, and hopefully some overall progress ;)
ttyl bero
On Sun, Jan 15, 2012 at 3:49 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
Unfortunately, we don't have infinite history on android-build (think just 1 build).
Not sure if we can grep some log from our server that isn't subject to our retention mechanisms? Maybe jenkins has more logs that date back longer?
2012/1/14 Zygmunt Krynicki zygmunt.krynicki@linaro.org:
Data from all the builds with from-device timestamp (from revision 15 of my script):
http://paste.ubuntu.com/804677/
Note: currently lava has no way to harvest build date or additional build meta-data. If you know of a way just ping me.
2012/1/15 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 14 January 2012 16:34, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Also, I see one critical piece missing that was requested - the
datestamp.
I know, we simply don't have any. The best that I can do is give you the submission timestamp.
That would be good (in the worst case I'd just check the build time of the build that was tested).
Bero, does this give you enough to go on for now? I requested staging-panda as an initial data set since it seems to be the most complete. The board type used is probably not important to mention in the graph anyway.
I can generate the data for any (all?) builds.
Please do, we want it to show something, and hopefully some overall progress ;)
ttyl bero
-- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Sun, Jan 15, 2012 at 7:48 PM, Alexander Sack asac@linaro.org wrote:
On Sun, Jan 15, 2012 at 3:49 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
Unfortunately, we don't have infinite history on android-build (think just 1 build).
Not sure if we can grep some log from our server that isn't subject to our retention mechanisms? Maybe jenkins has more logs that date back longer?
I would recommend to store the build date as an attribute 'android.build-date' in the standard format 'yyyy-mm-ddThh:mm:ssZ', we can harvest that in lava and will build improved history for the future.
Best regards ZK
2012/1/14 Zygmunt Krynicki zygmunt.krynicki@linaro.org:
Data from all the builds with from-device timestamp (from revision 15 of my script):
http://paste.ubuntu.com/804677/
Note: currently lava has no way to harvest build date or additional build meta-data. If you know of a way just ping me.
2012/1/15 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 14 January 2012 16:34, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Also, I see one critical piece missing that was requested - the
datestamp.
I know, we simply don't have any. The best that I can do is give you the submission timestamp.
That would be good (in the worst case I'd just check the build time of the build that was tested).
Bero, does this give you enough to go on for now? I requested staging-panda as an initial data set since it seems to be the most complete. The board type used is probably not important to mention in the graph anyway.
I can generate the data for any (all?) builds.
Please do, we want it to show something, and hopefully some overall progress ;)
ttyl bero
-- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
-- 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
On 15 January 2012 14:14, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Sun, Jan 15, 2012 at 7:48 PM, Alexander Sack asac@linaro.org wrote:
On Sun, Jan 15, 2012 at 3:49 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
Unfortunately, we don't have infinite history on android-build (think just 1 build).
Not sure if we can grep some log from our server that isn't subject to our retention mechanisms? Maybe jenkins has more logs that date back longer?
I would recommend to store the build date as an attribute 'android.build-date' in the standard format 'yyyy-mm-ddThh:mm:ssZ', we can harvest that in lava and will build improved history for the future.
Great idea! I'll put it on my ask list.
Best regards ZK
2012/1/14 Zygmunt Krynicki zygmunt.krynicki@linaro.org:
Data from all the builds with from-device timestamp (from revision 15 of my script):
http://paste.ubuntu.com/804677/
Note: currently lava has no way to harvest build date or additional build meta-data. If you know of a way just ping me.
2012/1/15 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 14 January 2012 16:34, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Also, I see one critical piece missing that was requested - the > datestamp.
I know, we simply don't have any. The best that I can do is give you the submission timestamp.
That would be good (in the worst case I'd just check the build time of the build that was tested).
> Bero, does this give you enough to go on for now? I requested > staging-panda as an initial data set since it seems to be the most > complete. The board type used is probably not important to mention in the > graph anyway.
I can generate the data for any (all?) builds.
Please do, we want it to show something, and hopefully some overall progress ;)
ttyl bero
-- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
-- 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
On Sun, 15 Jan 2012 21:14:05 +0100 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Sun, Jan 15, 2012 at 7:48 PM, Alexander Sack asac@linaro.org wrote:
On Sun, Jan 15, 2012 at 3:49 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
Unfortunately, we don't have infinite history on android-build (think just 1 build).
Not sure if we can grep some log from our server that isn't subject to our retention mechanisms? Maybe jenkins has more logs that date back longer?
I would recommend to store the build date as an attribute 'android.build-date' in the standard format 'yyyy-mm-ddThh:mm:ssZ', we can harvest that in lava and will build improved history for the future.
If it would useful to start doing that from now on, yes that can be added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Best regards ZK
2012/1/14 Zygmunt Krynicki zygmunt.krynicki@linaro.org:
Data from all the builds with from-device timestamp (from revision 15 of my script):
http://paste.ubuntu.com/804677/
Note: currently lava has no way to harvest build date or additional build meta-data. If you know of a way just ping me.
2012/1/15 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 14 January 2012 16:34, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Also, I see one critical piece missing that was requested - the > datestamp.
I know, we simply don't have any. The best that I can do is give you the submission timestamp.
That would be good (in the worst case I'd just check the build time of the build that was tested).
> Bero, does this give you enough to go on for now? I requested > staging-panda as an initial data set since it seems to be the > most complete. The board type used is probably not important > to mention in the graph anyway.
I can generate the data for any (all?) builds.
Please do, we want it to show something, and hopefully some overall progress ;)
ttyl bero
-- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
-- 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
On Mon, Jan 16, 2012 at 1:44 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Sun, 15 Jan 2012 21:14:05 +0100 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Sun, Jan 15, 2012 at 7:48 PM, Alexander Sack asac@linaro.org wrote:
On Sun, Jan 15, 2012 at 3:49 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
Unfortunately, we don't have infinite history on android-build (think just 1 build).
Not sure if we can grep some log from our server that isn't subject to our retention mechanisms? Maybe jenkins has more logs that date back longer?
I would recommend to store the build date as an attribute 'android.build-date' in the standard format 'yyyy-mm-ddThh:mm:ssZ', we can harvest that in lava and will build improved history for the future.
If it would useful to start doing that from now on, yes that can be added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Yes, having our build data go into central lava database next to the test results etc. can only be beneficial and would be awesome. Would we replay the data for the builds of last three month?
On this front to remember to think about: How can we ensure that bundles don't get lost if lava is temporarily down?
On Mon, 16 Jan 2012 13:55:32 +0100 Alexander Sack asac@linaro.org wrote:
[]
If it would useful to start doing that from now on, yes that can be added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Yes, having our build data go into central lava database next to the test results etc. can only be beneficial and would be awesome. Would we replay the data for the builds of last three month?
Long time ago I proposed that LAVA to become the CI central, collecting and displaying all the needed data, instead of random-patching Android Build to display CI data. That didn't catch much attention then...
On this front to remember to think about: How can we ensure that bundles don't get lost if lava is temporarily down?
On Mon, Jan 16, 2012 at 2:25 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Mon, 16 Jan 2012 13:55:32 +0100 Alexander Sack asac@linaro.org wrote:
[]
If it would useful to start doing that from now on, yes that can be added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Yes, having our build data go into central lava database next to the test results etc. can only be beneficial and would be awesome. Would we replay the data for the builds of last three month?
Long time ago I proposed that LAVA to become the CI central, collecting and displaying all the needed data, instead of random-patching Android Build to display CI data. That didn't catch much attention then...
I always run around like a headless chicken asking for the same!
Thanks ZK
On Mon, 16 Jan 2012 14:39:14 +0100, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Mon, Jan 16, 2012 at 2:25 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Mon, 16 Jan 2012 13:55:32 +0100 Alexander Sack asac@linaro.org wrote:
[]
If it would useful to start doing that from now on, yes that can be added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Yes, having our build data go into central lava database next to the test results etc. can only be beneficial and would be awesome. Would we replay the data for the builds of last three month?
Long time ago I proposed that LAVA to become the CI central, collecting and displaying all the needed data, instead of random-patching Android Build to display CI data. That didn't catch much attention then...
I always run around like a headless chicken asking for the same!
I think we should probably seriously think about how we can move things in this direction. Something to talk about over coffee/beer at the connect?
Cheers, mwh
On 01/17/2012 12:33 AM, Michael Hudson-Doyle wrote:
On Mon, 16 Jan 2012 14:39:14 +0100, Zygmunt Krynickizygmunt.krynicki@linaro.org wrote:
On Mon, Jan 16, 2012 at 2:25 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Mon, 16 Jan 2012 13:55:32 +0100 Alexander Sackasac@linaro.org wrote:
[]
If it would useful to start doing that from now on, yes that can be added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Yes, having our build data go into central lava database next to the test results etc. can only be beneficial and would be awesome. Would we replay the data for the builds of last three month?
Long time ago I proposed that LAVA to become the CI central, collecting and displaying all the needed data, instead of random-patching Android Build to display CI data. That didn't catch much attention then...
I always run around like a headless chicken asking for the same!
I think we should probably seriously think about how we can move things in this direction. Something to talk about over coffee/beer at the connect?
I'd love to be there with a virtual screen as I'm not coming :/
ZK
Hi, All
there are some build information we can get from the deployed android. like these: 11:03:19 liuyq:landing-panda$ adb shell getprop|grep build [ro.build.characteristics]: [tablet,nosdcard] [ro.build.date.utc]: [1326680337] [ro.build.date]: [Mon Jan 16 02:18:57 UTC 2012] [ro.build.description]: [pandaboard-eng 4.0.3 IML74K 31 test-keys] [ro.build.display.id]: [pandaboard-eng 4.0.3 IML74K 31 test-keys] [ro.build.fingerprint]: [pandaboard/pandaboard/pandaboard:4.0.3/IML74K/31:eng/test-keys] [ro.build.host]: [ip-10-6-109-237] [ro.build.id]: [IML74K] [ro.build.product]: [pandaboard] [ro.build.tags]: [test-keys] [ro.build.type]: [eng] [ro.build.user]: [jenkins-build] [ro.build.version.codename]: [REL] [ro.build.version.incremental]: [31] [ro.build.version.release]: [4.0.3] [ro.build.version.sdk]: [15] 11:08:52 liuyq:landing-panda$
should we add those to the result bundle?
**At now, only the "ro.build.display.id" has been added to the result bundle.
Thanks, Yongqin Liu On 17 January 2012 07:59, Zygmunt Krynicki zygmunt.krynicki@linaro.orgwrote:
On 01/17/2012 12:33 AM, Michael Hudson-Doyle wrote:
On Mon, 16 Jan 2012 14:39:14 +0100, Zygmunt Krynicki<zygmunt.krynicki@** linaro.org zygmunt.krynicki@linaro.org> wrote:
On Mon, Jan 16, 2012 at 2:25 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Mon, 16 Jan 2012 13:55:32 +0100 Alexander Sackasac@linaro.org wrote:
[]
If it would useful to start doing that from now on, yes that can be
added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Yes, having our build data go into central lava database next to the test results etc. can only be beneficial and would be awesome. Would we replay the data for the builds of last three month?
Long time ago I proposed that LAVA to become the CI central, collecting and displaying all the needed data, instead of random-patching Android Build to display CI data. That didn't catch much attention then...
I always run around like a headless chicken asking for the same!
I think we should probably seriously think about how we can move things in this direction. Something to talk about over coffee/beer at the connect?
I'd love to be there with a virtual screen as I'm not coming :/
ZK
On Tue, Jan 17, 2012 at 4:14 AM, yong qin yongqin.liu@linaro.org wrote:
Hi, All
there are some build information we can get from the deployed android. like these: 11:03:19 liuyq:landing-panda$ adb shell getprop|grep build [ro.build.characteristics]: [tablet,nosdcard] [ro.build.date.utc]: [1326680337] [ro.build.date]: [Mon Jan 16 02:18:57 UTC 2012] [ro.build.description]: [pandaboard-eng 4.0.3 IML74K 31 test-keys] [ro.build.display.id]: [pandaboard-eng 4.0.3 IML74K 31 test-keys] [ro.build.fingerprint]: [pandaboard/pandaboard/pandaboard:4.0.3/IML74K/31:eng/test-keys] [ro.build.host]: [ip-10-6-109-237] [ro.build.id]: [IML74K] [ro.build.product]: [pandaboard] [ro.build.tags]: [test-keys] [ro.build.type]: [eng] [ro.build.user]: [jenkins-build] [ro.build.version.codename]: [REL] [ro.build.version.incremental]: [31] [ro.build.version.release]: [4.0.3] [ro.build.version.sdk]: [15] 11:08:52 liuyq:landing-panda$
This reminds me:
can we replace or add something that includes our linaro-android build id? e.g. https://android-build.linaro.org/builds/~linaro-android/tracking-panda/#buil...
Blueprint or Bug?
Hello Alexander,
On Tue, 17 Jan 2012 10:42:04 +0100 Alexander Sack asac@linaro.org wrote:
On Tue, Jan 17, 2012 at 4:14 AM, yong qin yongqin.liu@linaro.org wrote:
Hi, All
there are some build information we can get from the deployed android. like these: 11:03:19 liuyq:landing-panda$ adb shell getprop|grep build [ro.build.characteristics]: [tablet,nosdcard] [ro.build.date.utc]: [1326680337] [ro.build.date]: [Mon Jan 16 02:18:57 UTC 2012] [ro.build.description]: [pandaboard-eng 4.0.3 IML74K 31 test-keys] [ro.build.display.id]: [pandaboard-eng 4.0.3 IML74K 31 test-keys] [ro.build.fingerprint]: [pandaboard/pandaboard/pandaboard:4.0.3/IML74K/31:eng/test-keys] [ro.build.host]: [ip-10-6-109-237] [ro.build.id]: [IML74K] [ro.build.product]: [pandaboard] [ro.build.tags]: [test-keys] [ro.build.type]: [eng] [ro.build.user]: [jenkins-build] [ro.build.version.codename]: [REL] [ro.build.version.incremental]: [31] [ro.build.version.release]: [4.0.3] [ro.build.version.sdk]: [15] 11:08:52 liuyq:landing-panda$
This reminds me:
can we replace or add something that includes our linaro-android build id? e.g. https://android-build.linaro.org/builds/~linaro-android/tracking-panda/#buil...
Blueprint or Bug?
I'd say a blueprint. We talked about something like that once, even more detailed info, like include manifest inside builds tarballs, so it was always possible to figure out what it was build from, similar to how kernel stores its git revision and config.gz.
And that's just one facet of the issue, another for example here: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-whats-i... (in "permanent backlog"). Yesterday's task of getting build stats can be see as another facet. And in general, the task is providing more universally available metadata about the builds, by various means, and yes, I guess it makes sense to dedicate planning and implementation time for that, by making it a blueprint.
On Mon, Jan 16, 2012 at 1:55 PM, Alexander Sack asac@linaro.org wrote:
On Mon, Jan 16, 2012 at 1:44 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Sun, 15 Jan 2012 21:14:05 +0100 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Sun, Jan 15, 2012 at 7:48 PM, Alexander Sack asac@linaro.org wrote:
On Sun, Jan 15, 2012 at 3:49 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
Unfortunately, we don't have infinite history on android-build (think just 1 build).
Not sure if we can grep some log from our server that isn't subject to our retention mechanisms? Maybe jenkins has more logs that date back longer?
I would recommend to store the build date as an attribute 'android.build-date' in the standard format 'yyyy-mm-ddThh:mm:ssZ', we can harvest that in lava and will build improved history for the future.
If it would useful to start doing that from now on, yes that can be added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Yes, having our build data go into central lava database next to the test results etc. can only be beneficial and would be awesome. Would we replay the data for the builds of last three month?
On this front to remember to think about: How can we ensure that bundles don't get lost if lava is temporarily down?
We were considering two options here:
1) Make each part of linaro infrastructure spool data instead of assuming lava is always up 2) Run a centralized spool in the cloud. This 'spool' would 'never' go down and would store&forward all requests back to the lab. This is harder to do because some of our requests reply with a response ID of some kind. We'd have to ensure that id can be client-assigned and that our key API is response-free.
ZK
On Mon, 16 Jan 2012 14:27:00 +0100, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Mon, Jan 16, 2012 at 1:55 PM, Alexander Sack asac@linaro.org wrote:
On Mon, Jan 16, 2012 at 1:44 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Sun, 15 Jan 2012 21:14:05 +0100 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Sun, Jan 15, 2012 at 7:48 PM, Alexander Sack asac@linaro.org wrote:
On Sun, Jan 15, 2012 at 3:49 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
Unfortunately, we don't have infinite history on android-build (think just 1 build).
Not sure if we can grep some log from our server that isn't subject to our retention mechanisms? Maybe jenkins has more logs that date back longer?
I would recommend to store the build date as an attribute 'android.build-date' in the standard format 'yyyy-mm-ddThh:mm:ssZ', we can harvest that in lava and will build improved history for the future.
If it would useful to start doing that from now on, yes that can be added. Otherwise, we'd need to join LAVA and Android Build data anyway, and primary key is (job_name, build_no), which is already present in LAVA (in the form of build URL).
Yes, having our build data go into central lava database next to the test results etc. can only be beneficial and would be awesome. Would we replay the data for the builds of last three month?
On this front to remember to think about: How can we ensure that bundles don't get lost if lava is temporarily down?
We were considering two options here:
- Make each part of linaro infrastructure spool data instead of
assuming lava is always up 2) Run a centralized spool in the cloud. This 'spool' would 'never' go down and would store&forward all requests back to the lab. This is harder to do because some of our requests reply with a response ID of some kind. We'd have to ensure that id can be client-assigned and that our key API is response-free.
Luckily though, I think option 2 is actually reasonably practical so long as we keep URLs working (for example, the URL a bundle ends up at is a function of the SHA-1 of the bundle, something the client can compute for itself).
Cheers, mwh
On Sat, 14 Jan 2012 20:49:53 -0600 Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Sure, Jenkins provides API to access information about the jobs and builds, starting page on that is here: https://android-build.linaro.org/jenkins/api/
Of course, as Alexander points out, the information is available for last 3 months (for daily builds).
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
2012/1/14 Zygmunt Krynicki zygmunt.krynicki@linaro.org:
Data from all the builds with from-device timestamp (from revision 15 of my script):
http://paste.ubuntu.com/804677/
Note: currently lava has no way to harvest build date or additional build meta-data. If you know of a way just ping me.
2012/1/15 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 14 January 2012 16:34, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Also, I see one critical piece missing that was requested - the
datestamp.
I know, we simply don't have any. The best that I can do is give you the submission timestamp.
That would be good (in the worst case I'd just check the build time of the build that was tested).
Bero, does this give you enough to go on for now? I requested staging-panda as an initial data set since it seems to be the most complete. The board type used is probably not important to mention in the graph anyway.
I can generate the data for any (all?) builds.
Please do, we want it to show something, and hopefully some overall progress ;)
ttyl bero
Paul, could you explain how to use this API to get the build history quickly? I'm bogged with other stuff before release but I'd like to help collect the missing pieces of history
On Mon, Jan 16, 2012 at 1:41 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Sat, 14 Jan 2012 20:49:53 -0600 Zach Pfeffer zach.pfeffer@linaro.org wrote:
Do you have a way we can dump the date and time of every build that we've done?
Sure, Jenkins provides API to access information about the jobs and builds, starting page on that is here: https://android-build.linaro.org/jenkins/api/
Of course, as Alexander points out, the information is available for last 3 months (for daily builds).
Then we can take the data Zygmunt produced and merge it with that data, and come up with our super cool graphs!
2012/1/14 Zygmunt Krynicki zygmunt.krynicki@linaro.org:
Data from all the builds with from-device timestamp (from revision 15 of my script):
http://paste.ubuntu.com/804677/
Note: currently lava has no way to harvest build date or additional build meta-data. If you know of a way just ping me.
2012/1/15 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 14 January 2012 16:34, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Also, I see one critical piece missing that was requested - the
datestamp.
I know, we simply don't have any. The best that I can do is give you the submission timestamp.
That would be good (in the worst case I'd just check the build time of the build that was tested).
Bero, does this give you enough to go on for now? I requested staging-panda as an initial data set since it seems to be the most complete. The board type used is probably not important to mention in the graph anyway.
I can generate the data for any (all?) builds.
Please do, we want it to show something, and hopefully some overall progress ;)
ttyl bero
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Mon, 16 Jan 2012 14:40:09 +0100 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Paul, could you explain how to use this API to get the build history quickly? I'm bogged with other stuff before release but I'd like to help collect the missing pieces of history
As I wrote in a later mail, I take this for myself, and will forward a CSV file with that info shortly (hopefully, within an hour). I'm still not sure who will produce charts from all that data though (but from android-build side, there're some graphs already, also in a later email.)
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Mon, 16 Jan 2012 16:23:54 +0200 Paul Sokolovsky Paul.Sokolovsky@linaro.org wrote:
On Mon, 16 Jan 2012 14:40:09 +0100 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Paul, could you explain how to use this API to get the build history quickly? I'm bogged with other stuff before release but I'd like to help collect the missing pieces of history
As I wrote in a later mail, I take this for myself, and will forward a CSV file with that info shortly (hopefully, within an hour). I'm still not sure who will produce charts from all that data though (but from android-build side, there're some graphs already, also in a later email.)
Ok, CSV data is available as http://people.linaro.org/~pfalcon/build-dates.csv
Also, a bit of aggregate stats:
$ ./jenkins-total-builds 2171
$ ./jenkins-total-duration 2902.98hrs
First number gives how many builds are currently in android-build (garbage-collected builds are not counted) and how many hours it took to build them.
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-android@lists.linaro.org
-
Alexander Sack -
Michael Hudson-Doyle -
Paul Sokolovsky -
yong qin -
Zach Pfeffer -
Zygmunt Krynicki