Open Bug 1607191 Opened 5 years ago Updated 2 years ago

Investigate subcomponent build metrics over-report on windows-mingw32

Categories

(Firefox Build System :: General, defect, P3)

defect

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.

Keywords: in-triage
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.