1616712 - [meta] Ensure that installers (stub and full) can build entirely in automation

Status: NEW

(Firefox :: Installer, enhancement, P5)

Description

[Nick Alexander :nalexander [he/him]]

Right now, the installers -- both stub and full -- use certain native code "plugins" to expand the functionality of the core NSIS installer-producing toolchain. The code for those plugins lives in the tree -- for example, https://searchfox.org/mozilla-central/source/other-licenses/7zstub -- but the process of building the plugins is delicate and often requires installing very particular toolchains to maintain a set of compatibility invariants that aren't well captured. This makes it difficult to iterate on the plugins and exposes Mozilla to a certain amount of risk: there is always a chance that a plugin will be functionally impossible to update in the future. This ticket tracks quantifying that risk and figuring out what a reasonable approach to building these plugins in automation might be.

Comment 1

[Nick Alexander :nalexander [he/him]]

P5 'cuz this isn't urgent. It might not even be possible or worth the effort! But I would like to have a place to talk about it, with a conversation recorded for the future.

In my mind I'm imagining some sequence of toolchain tasks that produce the various plugins (partial list) and DLL files required. I'm not sure there's any value around the third-party plugins but building the 7zstub in automation sounds worthwhile.

I imagine that this interacts with mach repackage, which works with artifact builds but might need to learn how to consume toolchain tasks in order to have the native code NSIS plugins available.

Comment 2

[Molly Howell (she/her) (mostly inactive)]

I want to avoid doing anything that would require building these binaries at installer build time in order to generate installers, because that would mean requiring that the build system has configured a toolchain in order to generate installers, and that's not the case in artifact builds, so having that requirement would mean installers cannot be generated from artifact builds.

But that's a distinct goal from enabling building all of these things with current tools and exposing that to our automation so that it can run builds for them, which is an idea I'm very much in favor of.

Also just as a minor clarification to comment 0, 7zstub isn't technically a plugin, it's the self-extractor binary that extracts the NSIS installer from the downloaded package; the NSIS plugins live in /other-licenses/nsis/. This bug applies to both the 7-zip stub and the NSIS plugins, since all of those things have pre-built binaries checked into the tree.

Comment 3

[Nick Alexander :nalexander [he/him]]

This might include producing nsisui.exe (nee modern.exe) in some way. This file is essentially a "binary input" to the build because it changes so infrequently (but see Bug 1596812).