Ability to get a pushlog range

[mstange]

It would be nice to select a point on a graph and get a pushlog link that shows the code changes compared to the build of the previous data point. Or the ability to select a range and get the pushlog for that range. For example, on this graph, there's a clear jump on August 26, but I need to jump through hoops to find out what changed in the 20160826 build: https://mzl.la/2cV5tIl

[chutten]

Sensible request, though I'm not sure how to programmatically get the pushlog. Could you detail the steps you used to get from a date to a sha range?

[mstange]

Not sure. @wlach might know where the code is that does this in perfherder.

[wlach]

Perfherder stores the SHA as part of the resultset, which it then uses to generate the pushlog. That said, if you have an exact timestamp of the push a build was based off of (YYYYMMDD doesn't cut it), that should be enough to derive a SHA for which to get a pushlog range.

[bsmedberg]

We've long had the problem in both telemetry and crash-stats where we know the buildid, but it's difficult to map that back to a cset. There is not an API that I know of which makes that mapping easy.

[mstange]

Ehsan and I have run into this problem again today.

[digitarald]

A script would check the ftp builds for the date range and get the SHAs from the text files in the right builds. I can take a shot at this for health.graphics as example script.

[chutten]

If you'd like to see some prior art on this, this is how medusa (alerts.tmo frontend) does it for telemetry-alerts emails: https://github.com/mozilla/medusa/blob/ea4bf27a4f71c740507cbed5d149bd900ee29c93/src/clj/medusa/changesets.clj

[mstange]

A script would check the ftp builds for the date range

But that's imprecise if we produced multiple nightlies on the same day, isn't it? Does telemetry even have the necessary information to distinguish those builds?

[bsmedberg]

The base telemetry data has the buildid. However it appears that the aggregation is currently being done by build day instead of buildid, which means we're losing that signal. Unfortunate and something to fix as a separate issue.

[mostlygeek]

We are working on a project, mozilla-services/buildhub, that may help with this. The project is still in a nascent stage, but we are looking at servicing this use case. BuildHub is meant to be a comprehensive database of build and release data.

It'd be a great help to get some direct feedback on needs from telemetry devs.

[digitarald]

But that's imprecise if we produced multiple nightlies on the same day, isn't it? Does telemetry even have the necessary information to distinguish those builds?

One could simply take the earliest build for start of regression range and latest build of a day for the end of regression range. Judging from various threads going around we only have one build per platform per day and can't seem to change that in the near future as a lot of pipelines assume one build a day and use date as unique key.

Looks like @chutten's reference already handles the process as I described.

[fbertsch]

Bug 1347564 is for adding capability to show multiple builds per nightly to TMO, so it looks like there was/is talk of this.

[mreid-moz]

Not sure if this helps, but the main ping contains the mercurial revision at payload.info.revision. We could build a map of [channel, build] -> revision(s)

[chutten]

This is pending mozilla-services/buildhub#36

[staktrace]

The buildhub dependency looks to be satisfied now. I would also like to see this implemented; I just ran into it.

[mstange]

I ran into this again today.

[chutten]

To manually get a pushlog: 1) Go to https://hg.mozilla.org/mozilla-central/firefoxreleases and find the Revisions of the last build before the change and the first build after the change. This is complicated somewhat by there being multiple builds per day, so all else fails widen your search by an extra build. 2) Put the revisions from Step 1 into this template: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange={}&tochange={}