(In reply to Michael Droettboom [:mdroettboom] from comment #2)
probe_scraper only needs to get "every metric defined for an app anywhere for all time", not the exact set of metrics for an exact version of an app. So that should mean that we don't need to have a mapping from a-c's
engine-gecko git commit hash to m-c's Mercurial hash.
Ok, that makes me feel a bit better about this.
Along with that idea, I don't think we need to take care about which of the branches (nightly, beta or release) Fenix is built with to determine where to look up the metrics. One might argue that we always want to look up in nightly's metrics.yaml for all channels -- that would at least be consistent with how things are done for a-c components now. That probably warrants a little discussion of course, as I only have a very high-level picture of how that works.
This is a bit tricky: some Gecko metrics, in general, might live in Nightly only or be removed before they reach Release. a-c's engine-gecko-* components thankfully map to different Gecko channels, so we should be safe by defining 3 different repos.
An additional wrinkle: I believe probe_scraper only supports git repositories -- it actually walks through the history of the
metrics.yaml files to find all metrics ever. It may be possible to use a mercurial-to-git bridge for this, rather than writing a new mercurial backend. I'm researching that now...
Maybe that's not even needed: Mozilla has a git read-only mirror of mozilla-central, here: https://github.com/mozilla/gecko-dev - the
master branch is nightly,
beta is beta and
release is release.