GNOME Bugzilla – Bug 733838
Add a map from revision to serial and target for each day
Last modified: 2014-08-01 07:15:28 UTC
These are some patches added to support the idea of hovering over points on perf.gnome.org and finding out what build the points correspond to and what changed. The way this is done is to have an index of the target revisions for each day - this is a bit conceptually weird, because we can then do the reverse map but only if we know the starting day - but it works for perf.gnome.org since we have both a revision ID and a time for each tested build, so we have to check at most a couple of days even counting for performance runs right near midnight. Other alternatives that I considered: * Have directory tree in 'af/123af1ec21231...' style with a json file for each target revision. Disadvantage here is that it's a HTTP request for each reverse query, and we often want to do many for adjacent builds. * Have a big master index - didn't like the idea of rewriting a large file on each build. * Redo gnome-hwtest and perf.gnome.org to work off successful builds and record a build serial (2014-07-21.41) for each metric run rather than polling the x86_64-runtime tree and building when that ref changes. This is probably the way I *should* have set things up, but I don't want to work on redoing it right now, so I'd appreciate consideration of this patch or other ways to do the reverse mapping.
Created attachment 281831 [details] [review] Add a map from revision to serial and target for each day For perf.gnome.org, we need the ability to map back from revision to a particular build, so we can use recorded build data to figure out what changed between measurements. We know within a few minutes when a build completed and measurement started, so it's sufficient to be able to do the map at day granularity, so add a map to each day's index.json that goes from revision to build serial and target.
Created attachment 281832 [details] [review] Add 'ostbuild update indices' to regenerate indices To be able to retroactively have the revision => target map for older builds, add a new builtin that regenerates the index.json for each day. (It could also regenerate indices on higher levels if we extend those in the future - right now there is no reason to rebuild them, so we don't.)
Review of attachment 281831 [details] [review]: There's a bit of an abstraction crossing here as versioneddir.js wasn't intended to know about Continuous builds, but it's OK by me.
Review of attachment 281832 [details] [review]: Looks fine.
(In reply to comment #3) > Review of attachment 281831 [details] [review]: > > There's a bit of an abstraction crossing here as versioneddir.js wasn't > intended to know about Continuous builds, but it's OK by me. Yeah - I would have put the logic that knows about builds in task-build.js except that I wanted to have 'ostbuild update-indices'
Attachment 281831 [details] pushed as fc48eb0 - Add a map from revision to serial and target for each day Attachment 281832 [details] pushed as f3f8cb2 - Add 'ostbuild update indices' to regenerate indices