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