Open Bug 1639383 Opened 4 years ago Updated 2 years ago

Autoland and mozilla-central builds have different MOZ_UPDATE_CHANNEL

Categories

(Firefox Build System :: Task Configuration, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: tcampbell, Unassigned)

References

Details

(Whiteboard: [perf:workflow])

Firefox builds on autoland use a MOZ_UPDATE_CHANNEL of nightly-autoland while m-c builds use nightly. This results in surprising differences between the two.

eg. https://treeherder.mozilla.org/perf.html#/graphs?highlightAlerts=1&series=autoland,2223760,1,4&series=mozilla-central,2223976,1,4&timerange=2592000
(This is otherwise a very stable metric)

The code that decides this is: https://searchfox.org/mozilla-central/rev/61fceb7c0729773f544a9656f474e36cd636e5ea/testing/mozharness/mozharness/mozilla/building/buildbase.py#631

Should we change the update channel of autoland to "nightly"?

Most try builds will end up with a channel of "default" (and not be MOZ_OFFICIAL) and are more similar to current-autoland than central.

Should we change the update channel of autoland to "nightly"?

Tom, do you have any thoughts about this or could recommend someone to ask?

Flags: needinfo?(mozilla)

This difference seems to affect whether extended telemetry is kept. It turns out that autoland builds use base telemetry only (same as Release), while m-c includes it (since it is a nightly promotion build).

https://searchfox.org/mozilla-central/rev/61fceb7c0729773f544a9656f474e36cd636e5ea/toolkit/components/telemetry/app/TelemetryUtils.jsm#296-303

This is responsible for the difference in JS memory usage.

From Firefox Telemetry's POV we're happy for these trees to have or not have full data recording enabled according to their own desires. Data upload should (as today) remain disabled, but recording into memory the full set of Telemetry (as we do in the wild for Nightly and Beta) is a choice that can be made based on which channel of build you wish to most closely mimic.

Either way shouldn't change tests and won't pollute any Telemetry data (because none is uploaded).

In case it's helpful, here's the full list of things that configure how Telemetry runs. And do let me know if you have any questions: it's annoyingly fiddly.

So, I was looking to briefly fix the perf difference and punt on the channel difference a bit (I don't have cycles to come to a consensus on the channel naming difference itself)

I wrote https://hg.mozilla.org/try/rev/630ec463cf3365ec557c5dccf821f1853429249f which adjusts the JS file in c#2 but after discussion with chutten and realizing there was more to change just for telemetry I decided to abandon that course because there is a long tail of comparisons for the update channel floating around anyway.

The cpp location for telemetry I was pointed at is https://searchfox.org/mozilla-central/source/modules/libpref/Preferences.cpp#3310-3402 incase someone else wants to chip away with my patch absent a channel unification.

Looking at try builds, it seems that they use a channel of nightly-try and do set MOZ_OFFICIAL=1. Would fixing try to also use a "nightly" channel help to close more of the gap between try builds and m-c? Being able to trust m-c vs try builds for perf measurements would reduce the need to push as many jobs to try to form perf baselines.

Priority: -- → P3
Flags: needinfo?(mozilla)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: General → Task Configuration

Aiui we explicitly made try and autoland a different channel earlier to avoid confusion or attempts to ship a nightly from the wrong branch. I'm not sure what the right solution is, but if we decide we want to flip this assumption, we should probably notify everyone in case someone feels strongly about not doing this.

Whiteboard: [perf:workflow]
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.