Bugzilla

We need to know how much CPU time our retriggers & backfills consume.
By "our", I refer to us, Perf sheriffs. Explicitly, this means:
* igoldan
* bebe
* marauder
* alexandrui

Code sheriffs' activity should be excluded from this query, as they're also doing intermittent monitoring via retriggers/backfills.

I believe the best way to define a query for this would be to use Mozilla's ActiveData recipes, which can be found [here](https://github.com/mozilla/active-data-recipes). Kyle Lahnakoski could assist you in adding it to the repo. Sarah Clements could provide more insights over the kind of data Treeherder stores & Joel Maher could provide more insights over related TaskCluster data, in case we need to query that too, so we have all pieces together. I believe the data is fragmented over these 2 projects.

An example would shed some light over why we need this.
Given an alert, let's say [alert #20770](https://treeherder.mozilla.org/perf.html#/alerts?id=20770), if we go to it's graph and zoom in [here](https://treeherder.mozilla.org/perf.html#/graphs?timerange=5184000&series=mozilla-inbound,1944525,1,10&series=autoland,1926735,0,10&zoom=1558933063731.367,1559097018105.2837,508.1460674157304,617.5661743045912), we'll be able to see multiple commits with data points stacking one on top of the other.
The associated Treeherder job view (which is [this one](https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&group_state=expanded&searchStr=linux%2Cx64%2Cquantumrender%2Cshippable%2Copt%2Craptor%2Cperformance%2Ctests%2Con%2Cfirefox%2Ctest-linux64-shippable-qr%2Fopt-raptor-tp6-6-firefox-e10s%2Crap%28tp6-6%29&tochange=44fa715640dd2a4d06014e6d5fdda63c52707188&fromchange=b89b3cda594adf29317f5d3ff9d615a9d3dcde11)) pretty clearly shows some of the commits which have multiple Rap(tp6-6) jobs. These are the jobs that produced the data we observe in the graph.
As each job is triggered by a specific user + mentions how much time it needed to run, we need to sum this kind of durations up.

To this sum, we then need to add the backfill time (when you select a job, click on the three dots from bottom-left, then click on "Backfill") of all backfills triggered by Perf sheriffs. It's likely some backfill jobs have other dependant jobs that need to run first. We should take those into account too, for extra precision.

We need to know how much CPU time our retriggers & backfills consume, for the Talos, Raptor & AWSY frameworks.
By "our", I refer to us, Perf sheriffs. Explicitly, this means:
* igoldan
* bebe
* marauder
* alexandrui

Code sheriffs' activity should be excluded from this query, as they're also doing intermittent monitoring via retriggers/backfills.

I believe the best way to define a query for this would be to use Mozilla's ActiveData recipes, which can be found [here](https://github.com/mozilla/active-data-recipes). Kyle Lahnakoski could assist you in adding it to the repo. Sarah Clements could provide more insights over the kind of data Treeherder stores & Joel Maher could provide more insights over related TaskCluster data, in case we need to query that too, so we have all pieces together. I believe the data is fragmented over these 2 projects.

An example would shed some light over why we need this.
Given an alert, let's say [alert #20770](https://treeherder.mozilla.org/perf.html#/alerts?id=20770), if we go to it's graph and zoom in [here](https://treeherder.mozilla.org/perf.html#/graphs?timerange=5184000&series=mozilla-inbound,1944525,1,10&series=autoland,1926735,0,10&zoom=1558933063731.367,1559097018105.2837,508.1460674157304,617.5661743045912), we'll be able to see multiple commits with data points stacking one on top of the other.
The associated Treeherder job view (which is [this one](https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&group_state=expanded&searchStr=linux%2Cx64%2Cquantumrender%2Cshippable%2Copt%2Craptor%2Cperformance%2Ctests%2Con%2Cfirefox%2Ctest-linux64-shippable-qr%2Fopt-raptor-tp6-6-firefox-e10s%2Crap%28tp6-6%29&tochange=44fa715640dd2a4d06014e6d5fdda63c52707188&fromchange=b89b3cda594adf29317f5d3ff9d615a9d3dcde11)) pretty clearly shows some of the commits which have multiple Rap(tp6-6) jobs. These are the jobs that produced the data we observe in the graph.
As each job is triggered by a specific user + mentions how much time it needed to run, we need to sum this kind of durations up.

To this sum, we then need to add the backfill time (when you select a job, click on the three dots from bottom-left, then click on "Backfill") of all backfills triggered by Perf sheriffs. It's likely some backfill jobs have other dependant jobs that need to run first. We should take those into account too, for extra precision.