Investigate subcomponent build metrics over-report on windows-mingw32
Categories
(Firefox Build System :: General, defect, P3)
Tracking
(Not tracked)
People
(Reporter: Pike, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: in-triage)
Spin-off from bug 1036563.
I've investigated the subcomponent times for l10n-check
and I've found bewildering values. There's just not a lot to do, and they report up to 20 minutes. Histogram query is at https://sql.telemetry.mozilla.org/queries/67361/source?p_start_date_67361=2019-11-01&p_end_date_67361=2020-01-06.
I've looked into those, https://sql.telemetry.mozilla.org/queries/67360/source?p_start_date_67360=2019-11-01, and investigated the logs of a few > 20mins, and only found logs that had a mismatch between the timestamps in the logs and the reported times.
Notably, https://firefoxci.taskcluster-artifacts.net/AUnaXic8RUOYUgJC6sRKYg/0/public/logs/live_backing.log reports some 20 minutes, but the log timestamps indicate more like 10 minutes. Same for https://firefoxci.taskcluster-artifacts.net/Ch3GOmtzToyRzCbGL8dKqg/0/public/logs/live_backing.log
This is data from the logs themselves that doesn't seem to line up.
For other windows builds, I found shorter times. Like, https://firefoxci.taskcluster-artifacts.net/cwfvThciT0OClvz-vNRAjA/0/public/logs/live_backing.log shows 4 minutes in the json and the timestamps seem to match that.
My take-away is that we have some level of systematic measurement problem here.
I've not tried to expand the research beyond the particular subcomponent time of l10n-check
, nor if this is just subcomponent or also component time.
Filing this to hopefully get to better understanding which data is affected here, by not-me doing a more thorough research.
Updated•2 years ago
|
Description
•