BYO Build Dashboard
I’m happy to announce that we’ve started publishing some build data we’ve been collecting for the past several months.
If you’re interested in build data, like what jobs get run on which machines, and how long they take, then the files at http://build.mozilla.org/builds will be of interest to you.
These are JSON dumps of build data collected for most of our systems since October. There is one file per 24-hour period, as well as one file for the past 4 hours of data. If you want to look at the format, the 4 hour file is easier to read; the other files don’t use any extra white space. All times should be interpreted as unix timestamps (seconds since Jan 1, 1970 00:00:00 UTC). The “requesttime” is a best-effort calculation of when a build was requested based on when the revision in question was pushed to hg, or when the unit test or talos run was triggered.
That’s it!
This should be enough data to get started writing some dashboards and other visualizations. I’d love to hear how people are using this data, and if there’s anything missing from the data provided that would be useful.
This is amazing stuff.
Getting the revision of a unittest isn’t that easy however.
The properties.fileUrl of a unittest box equals properties.packageUrl of a build box which has properties.got_revision.
Lets see how I can put this to good use in tbpl
This is awesome! I know I asked you this on IRC, but how often is this data updated? Could tinderboxpushlog use this in place of scraping tinderbox?
Is that an export from the build db?
And, how often do the files get updated?
Axel: yeah, this is an export from the build db, so we can tweak the output format and re-generate these files if required.
Arpad: it’s a bit annoying, I know…we might be able to fix that in our code. All the old data would still be missing that information though.
The files are currently being generated about every 10 minutes from the database, and then synchronized to the web head every hour.
There’s no way to get the build logs, thanks to tinderbox, right? I guess the best we could do is link to the time range on the tinderbox page?
Filed bug 550181 to import the results into the l10n dashboard.
Right, tinderbox makes it impossible for us to link to the logs right now. We’re going to deal with this in bug 530318.
Another thing: leak test builds have properties.leakStats and properties.testresults. opt builds have properties.testresults with codesighs. Unittest and Talos don’t have anything there.
Hm synchronized every hour to the web, that doesn’t sound like it may be useful to tbpl.
What kind of properties would you like to see for unittest and talos runs?
We can look at synchronizing more often. What frequency is useful? Unfortunately we don’t get any data until a build is finished, so this won’t help with displaying information for in-progress builds.
Why don’t you get at least a good deal of that data from running builds?
Axel – because we’re not using an in-process status plugin. We’re just looking at the information that gets saved to disk after the build is finished.