1461484 - Make it easier to differentiate a full clone/update from a partial one

Status: REOPENED

(Developer Services :: Mercurial: robustcheckout, enhancement)

Description

[Gregory Szorc [:gps]]

The Perfherder metrics we added in bug 1448204 are a good start. But as I poke around with ActiveData queries, it is pretty obvious they are lacking in granularity. For example, the median "clone" time is ~3.3s. That's presumably due to the median job already having a local clone and not having to perform a full clone.

We'll want to supplement the metrics so we can differentiate between e.g. an `hg update` from no checkout versus an `hg update` from an existing checkout.

I haven't fully thought things through. But the first idea that comes to mind is to shoehorn "tags" into the "extraOptions" field. e.g. if an update is to a fresh working directory, we set "extraOptions": ["full"] for that data point. Then we can group each metric by the set of extraOptions and drill down to see which operations are taking the longest.

Comment 1

[Kyle Lahnakoski [:ekyle]]

Can you have the name of the metric depend on the type of clone performed? That seems to be what the other automation does; for example, adding "-opt" to the suite name.

You may add any strings you want to the "extraOptions" field, but note that the ec2 machine type is already included, so grouping by that column will be more difficult.

Comment 2

[Gregory Szorc [:gps]]

Yes, we could change the metric depending on the type of clone. A complication is that there are a few different axes that metrics will vary by. e.g. initial clone versus incremental clone and full clone versus partial clone. And we may have an existing working directory versus no working directory.

Comment 3

[Dave Hunt [:davehunt] [he/him] ⌚BST]

We're talking about removing the vcs data from Perfherder in bug 1692409.

Comment 4

[:glob ✱]

While the data is being removed from Perfherder itself, we still want it visible in STMO via the TC ETL, so this bug is still relevant.