Closed Bug 1498689 Opened 11 months ago Closed 5 months ago
Provide a way for partner builds (and funnelcakes) to use the stub installer
47 bytes, text/x-phabricator-request
|Details | Review|
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.
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
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.
Assignee: nobody → mhowell
Status: NEW → ASSIGNED
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/1922e2efbb65 Support partner builds changing the stub installer download URL. r=agashlin,mkaply
You need to log in before you can comment on or make changes to this bug.