Closed Bug 1498689 Opened 11 months ago Closed 5 months ago

Provide a way for partner builds (and funnelcakes) to use the stub installer

Categories

(Firefox :: Installer, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
Firefox 68
Tracking Status
firefox68 + fixed

People

(Reporter: mkaply, Assigned: mhowell)

References

Details

Attachments

(1 file)

Currently, whenever we do partner builds or funnelcakes, we have to use the full installer.

That has a couple disadvantages:

1. We lose the 64/32 bit Windows check.
2. Standard problem of abandonment on large download.

We should see if we can figure out a way to do stub installers for partner builds.

It would involve somehow binding the download URL to the stub externally so it could be done outside of a standard build process.
Would this require the ability to customize any branding strings/images as well?
> Would this require the ability to customize any branding strings/images as well?

No. Our current full installer partner builds don't have any brand customizations.

Might be a nice to have thing at some point in the future, though.
Okay, so just the download URL, thanks.

Right now that gets baked into setup-stub.exe because it's an NSIS constant. But I'm not really sure how to meaningfully improve on that. Artifact builds already run the installer build, so a full build isn't necessary to change the URL. We could move it out into something like an INI file that gets packed up next to setup-stub.exe, but that doesn't really save a lot of steps; the packing process itself is nontrivial. The "dummy certificate" area that's used for attribution data is off-limits because this is not something that should be allowed to change after the package is signed. The only other place I can think of to put it is a string resource on the 7-zip stub, which is not exactly convenient (either to set or to read).

How far outside of a standard build process do you think we need to be able to get?
> How far outside of a standard build process do you think we need to be able to get?

That's really up to releng. If they think we could rerun NSIS, that would be interesting.

Adding nthomas for his thoughts.
Flags: needinfo?(nthomas)
Storing the URL in an INI file inside the stub installer sounds like the most promising idea to me. We can likely use the existing 'mach repackage' code in-tree to handle calling NSIS. I think artifact builds are probably a bit heavier than doing that, and are currently only tier2 for linux on treeherder.

Experience says it's better for the vanilla builds to use the same mechanism as repacks, so any future bustage/regressions are visible asap instead of at some release in the future. This does make it more involved to transition vanilla builds because it requires some taskgraph work as well as NSIS. 


More details for future me - the mach repackage calls for full and stub installer differ by '--package-name firefox' and '--package ....fetches\target.zip' for the former, plus expected --tag, --setupexe, and --output. If we start passing a zip for the stub (which only contain the INI) it should work. The upstream build/partner repack job has to produce the target-stub.zip for this. The partner repackage jobs & script would need to be taught about stubs, probably dependent on a repack.cfg config value because external partners seem unlikely to need a stub. Downstream of repackage, the partner signing and beetmover tasks would also need to learn about stubs. Also fun, we build the vanilla stub in win32 builds, so win64=true && win32=false && winstub=true in a repack.cfg is a future footgun.

Relevant code:
@SubCommand('repackage', 'installer', https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/mach_commands.py#2761
repackage_installer(): https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/repackaging/installer.py#14
Flags: needinfo?(nthomas)
So I guess there would be two parts here:

1. Getting installer to support an INI with download path.
2. Releng to do the repackaging
Okay, that was super helpful, thanks guys. It sounds like we're all agreed that the INI file is the way to go. That prevents having to run NSIS a second time and it should be a pretty simple patch on the installer side.

Just to make sure I have all the requirements straight: since you specifically mentioned the 32/64 bit selection feature, I assume this will need to support URL's for both of those. I think that's the only complication?
> Just to make sure I have all the requirements straight: since you specifically mentioned the 32/64 bit selection feature, I assume this will need to support URL's for both of those. I think that's the only complication?

That's the only one I see.

The other interesting part is partner builds will always have to be public, but that's just life (and it's not your issue).
Am I right, that this issue'll be released in the Firefox 64?
(In reply to Vasilisa from comment #9)
> Am I right, that this issue'll be released in the Firefox 64?

No, there has been no work done here yet.
See also bug 916666.

Nick, we're considering this as a Q2 activity with the 68 release train but there are releng dependencies, can you please confirm if this is something releng could support us on in Q2?

Flags: needinfo?(nthomas)

I'll talk to catlee and let you know.

Yes, we could work on this in Q2. I'll file a separate bug for RelEng code changes.

Flags: needinfo?(nthomas)
Assignee: nobody → mhowell
Status: NEW → ASSIGNED
Pushed by mhowell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1922e2efbb65
Support partner builds changing the stub installer download URL. r=agashlin,mkaply
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

Hi,

IIUC, if the installation is somehow interrupted, the stub installer will still take the user to mozilla.org for a vanilla full installer.

Is this expected? Or should we make the URLManualDownload configurable, too?

Hector:

Can you open a separate bug for that?

(In reply to Mike Kaply [:mkaply] from comment #19)

Hector:

Can you open a separate bug for that?

Filed as bug 1558090.

See Also: → 1558090

Hi Nick, can you please update on status? We have only 2 days left to land to then allow for QA or this would be pushed to 70

Flags: needinfo?(nthomas)

This is almost ready to land and will make 69.

Flags: needinfo?(nthomas)

The release automation changes landed on central for 69, see bug 1538995 comment #24.

You need to log in before you can comment on or make changes to this bug.