Print a mozilla-central pushlog for Fenix regression windows
Categories
(Testing :: mozregression, enhancement)
Tracking
(Not tracked)
People
(Reporter: botond, Assigned: tcampbell)
References
Details
Attachments
(1 file, 1 obsolete file)
Bug 1556042 recently added support for finding a Fenix regression window with nightly granularity.
This unlocks for me a couple of use cases that --app gve wasn't suitable for:
- Regressions in browser features that are not implemented in GVE (e.g. pull-to-refresh)
- Older regressions where we don't have GVE builds going back that far
For platform regressions, the output of the regression-window-finding process that I'm looking for is a mozilla-central pushlog.
I get this with --app gve, but --app fenix doesn't currently print such a pushlog. Would it be possible to add this? I guess it would involve consulting some record of what mozilla-central revision a given Fenix nightly was built against.
Comment 1•1 year ago
|
||
This should be easier now that Fenix is in mozilla-central, at least for Fenix builds after the migration.
Comment 2•1 year ago
|
||
It still only prints out the dates of the before/after builds.
To get the revisions, you have to:
- Use
mozregression --launch <date>to launch the before/after builds. - Get the mozilla-central revision from the About panel in Fenix.
Comment 3•9 months ago
|
||
Bug 1979623 is another bug where this functionality would have been useful.
Comment 4•9 months ago
|
||
+1, it would have been useful to have a pushlog on bug 1976032 comment 3. It adds another layer to the mystery when trying to find a regressor.
I looked a bit to see if it's easy to implement. It looks like this buildId and revision url information is coming from an additional txt file that's generated and put in the same directory with the binary in archive.mozilla.org. For example,
Nightly archive directory:
https://archive.mozilla.org/pub/firefox/nightly/2025/07/2025-07-03-20-38-03-mozilla-central/
That txt file:
https://archive.mozilla.org/pub/firefox/nightly/2025/07/2025-07-03-20-38-03-mozilla-central/firefox-142.0a1.en-US.mac.txt
It seems like we don't generate this file for fenix binaries:
https://archive.mozilla.org/pub/fenix/nightly/2025/07/2025-07-03-20-38-03-fenix-142.0a1-android-arm64-v8a/
This _fetch_build_info_from_url function is the place where we try to fetch this file:
https://github.com/mozilla/mozregression/blob/fd9a8af13a11c3e0d25164f0d21029e360ec7e6c/mozregression/fetch_build_info.py#L183-L202 (See the build_txt_url in here.)
I see that a lot more files were generated for fennec that we don't generate anymore: https://archive.mozilla.org/pub/mobile/nightly/2020/01/2020-01-03-22-45-37-mozilla-esr68-android-x86/
I don't exactly know where else we use these files but it might be good to add them back.
I see this file is coming from: https://searchfox.org/mozilla-central/rev/ca035d76ad92757859375c2dc807c7a61055823b/taskcluster/gecko_taskgraph/manifests/firefox_nightly.yml#156-160
And we don't have a similar mapping for fenix apk/aab: https://searchfox.org/mozilla-central/rev/ca035d76ad92757859375c2dc807c7a61055823b/taskcluster/android_taskgraph/manifests/apk_candidates.yml#68-108
But fixing this will change the future releases only as I don't think we can retroactively push these txt files to older ones. Maybe there could be another fix/workaround inside the mozregression codebase for them?
Comment 6•9 months ago
|
||
There are routes in the taskcluster index for Fenix Nightlies, e.g. https://firefox-ci-tc.services.mozilla.com/tasks/index/gecko.v2.mozilla-central.pushdate.2025.08.07.20250807093834.mobile/fenix-nightly
And we can get the corresponding revision from the task.
Does mozregression have a way to use the taskcluster index rather than archive.mozilla.org for finding the builds?
| Assignee | ||
Comment 7•5 months ago
|
||
I'm putting together some patches for this. Using https://hg.mozilla.org/mozilla-central/json-pushes API I can query similar to what is suggested in Comment 6, but with a longer time window (since archive.mozilla.org artifacts also outlast taskcluster artifacts).
Additionally, with that fixed it is actually straightforward to support fine-grain bisection on autoland. The one remaining wrinkle I have on my list is to sort out nightly vs nightlySim builds which are basically the same for our needs but have have different schedules on m-c vs autoland.
(As a side note, it might be good to apply the same "shippable" build cleanup effort we did on Desktop but to Fenix rather than this "nightlysim" nomenclature).
Comment 8•5 months ago
|
||
| Assignee | ||
Comment 9•5 months ago
|
||
| Assignee | ||
Updated•5 months ago
|
Description
•