Closed Bug 1475512 Opened Last year Closed Last year

Integrate MSI installer inside CI system

Categories

(Firefox Build System :: General, enhancement)

Other Branch
enhancement
Not set

Tracking

(firefox65 fixed)

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: RT, Assigned: Callek)

References

(Depends on 1 open bug)

Details

(Whiteboard: [releng:q32018])

User Story

Context: 
We're planning to ship an MSI installer in 64 - this installer is a simple wrapper of the full installer exe and is intended for enterprises using active directory environments where msi installers are more convenient. See bug 1475510 that tracks the MSI installer creation.

Acceptance criteria:
- Add MSI as a new build product (an additional packaging format that wraps the existing full installer, for Windows only)
- Get the tools for generating the MSI (which come from https://github.com/wixtoolset/wix3/releases/), hook that into the build system
- Sign the MSI (which Matt believes osssigncode can do using our existing certificates)
- Make the result available for distribution.

Note: Per https://bugzilla.mozilla.org/show_bug.cgi?id=1475510#c2 we'll be using  WIX variables for details such as the language, version, platform, package/upgrade codes, and installer file, to maks it easier for the build system to be able to fill in that kind of information (which has to be done during build time)

Attachments

(5 files)

No description provided.
User Story: (updated)
Depends on: 1475510
Cool. An MSI installed should be useful!

Are there people signed up to do the build/CI work yet? Or are you filing this bug as the first step in that process?

Historically installers are managed by Release Engineering (catlee's team). So this bug may be misfiled. Although there are build system components to installers. The division of code/responsibility in this area is not always clear cut :)
Flags: needinfo?(rtestard)
I talked to Chris Atlee and Kim Moir about this and I understand Kim could help us there but perhaps I'm filing this in the wrong place. Kim, could you please advise who should be owning this bug?
Flags: needinfo?(rtestard) → needinfo?(kmoir)
User Story: (updated)
So a few questions/comments

1)  Yes, it is a bit confusing as to who owns what.  Upon re-reading the requirements, it does seem like it belongs to releng, and I'll ni catlee for confirmation.

2)  When we moved to taskcluster, we decoupled the build and sign process into separate tasks.  When you say  "- Add MSI as a new build product (an additional packaging format that wraps the existing full installer, for Windows only)" The requirement is to add the MSI installer available for download just like we have a stub-installer today?

3) You mention that this is required for Firefox 64.  I looked at the trello board for Firefox 64 features and I don't see this listed yet.  Is this feature being tracked by a PM?
Flags: needinfo?(kmoir) → needinfo?(catlee)
I agree that there is releng work here. Namely with build and release taskgraph integration.

callek is on point and can help with the following:

* grab the external tools required (possibly using tooltool)
* taskgraph integration
** get the installer signed using releng signing servers
** make the installer artifact available on archive.m.o
* sanity check l10n pieces

From the build team, it would be great to have assistance integrating whatever we need from the build system (mach build/repackage). We can create a couple bugs to divide this work or use this one. Kim, who could help with this?
Flags: needinfo?(catlee) → needinfo?(kmoir)
We have a team meeting tomorrow, I'll get back to you after it to see who can help.
Flags: needinfo?(kmoir)
From IRC discussion

kmoir-mtg: not sure anyone does, but given the info in that bug i think that would best be done as a repack
10:48 AM 
<•ted> Ted Mielczarek since it's going to take the existing installer as input and spit out an msi
10:48 AM → francois joined (francois@moz-cnggv3.fmarier.org)
10:49 AM 
<Callek_cloud9> ted: I was imagining it done as part of ./mach repackage
10:49 AM 
<•ted> Ted Mielczarek that's what i was thinking as well
10:50 AM 
<Callek_cloud9> ted: but if its necessary we could do it as an entirely seperate task after the first ./mach repackage + repackage-signing is run
10:50 AM 
<•ted> Ted Mielczarek what do we currently use the repackage task for?
10:50 AM 
<Callek_cloud9> ted: basically the piece that matters most  is "do we need the signed installer first, for the .msi or can we take the unsigned installer and sign the msi"
10:50 AM 
<•ted> Ted Mielczarek yeah, good point
10:51 AM 
<Callek_cloud9> ted: we build unsigned en-US [and l10n] and setup{,-stub}.exe (unsigned) for installer. Sign all the binaries in the .zip and the setup.exe, then off to ./mach repackage for stub and installer, then pass THOSE off to signing and then finally we can ship those bits
10:52 AM if the .msi needs to be after the signing of the installer then taskgraph is a bit harder but still doable, if it doesn't need to be after the installer signing then my end is a lot easier and potentially yours is as well
10:53 AM ted: the one caveat emptor is I think we still need the build task to be (able) to build the msi for local dev.  But our CI doesn't need to do it
10:53 AM 
<•ted> Ted Mielczarek gotcaha
10:53 AM well, i'd be fine with making local devs do "mach package; mach repack ..." to get an msi
10:53 AM we could add a nicer mach command if needed
10:54 AM 
<Callek_cloud9> yea I'm less concerned with local devs at this moment than I am with CI
10:54 AM 
<Pike> ./mach Paket
10:54 AM 
<Callek_cloud9> ted: do you know if all locales will need an msi as well?
10:54 AM (or is that to be determined/discussed)
10:55 AM 
<•ted> Ted Mielczarek IDK!

:RT do we need an msi per locale or is this just for en-US?
Flags: needinfo?(rtestard)
My understanding is that in order to provide all locales for Enterprise deployments we'll need an MSI per locale although there may be tricks there through the use of MSI properties.
Matt and Mike, do you know of a better way to do it?
Also I'm ccIng Zibi in case he has comments on timelines for multilingual builds (once we have multilingual builds I'd assume we could select a language through an MSI property at install time).
Flags: needinfo?(rtestard)
Flags: needinfo?(mozilla)
Flags: needinfo?(mhowell)
Flags: needinfo?(gandalf)
> Matt and Mike, do you know of a better way to do it?

I don't know of any. Are we going to allow folks to rebuild the MSI?
Flags: needinfo?(mozilla)
See Also: → 1476980
See Also: → 1476983
Whiteboard: [releng:q32018]
> My understanding is that in order to provide all locales for Enterprise deployments we'll need an MSI per locale

Why not multi-locale MSI?
Flags: needinfo?(gandalf) → needinfo?(rtestard)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #9)
> > My understanding is that in order to provide all locales for Enterprise deployments we'll need an MSI per locale
> 
> Why not multi-locale MSI?

It's ideal though is that feasible? Locale could be an MSI property?
Flags: needinfo?(rtestard)
releng can glue the build and l10n pieces together. And can do so in Q3. We will need a decision though on l10n and the approach we take. Specifically on whether multi-locale is doable or if we are doing an msi per locale. If we can do multi-locale, when will it will be ready for us to use?. cc gandalf?
Flags: needinfo?(gandalf)
I don't think I'm the right person to ask here. I've been driving the conversation behind the build-system part of Multilingual Firefox metaproject, and ability to build multilocale installer has been a part of it, but I have not done any work on our installer, so I don't know what we need to make that happen.

From my naive understansing:
 - we need a way to instruct the build system which locales to package into the installer (:ted? :nalexander?)
 - we need a way to package an installer with those locale resources (:ted?)
 - we need to be able to pick the right locale at runtime (probably from the OS locale) - not sure who?
Flags: needinfo?(gandalf)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #12)
> I don't think I'm the right person to ask here. I've been driving the
> conversation behind the build-system part of Multilingual Firefox
> metaproject, and ability to build multilocale installer has been a part of
> it, but I have not done any work on our installer, so I don't know what we
> need to make that happen.
> 
> From my naive understansing:
>  - we need a way to instruct the build system which locales to package into
> the installer (:ted? :nalexander?)
>  - we need a way to package an installer with those locale resources (:ted?)
>  - we need to be able to pick the right locale at runtime (probably from the
> OS locale) - not sure who?

This is an Enterprise use case where sys admins are expected to make this choice for end-users.
My interpretation is that we would wrap a full installer exe that includes all locales inside the MSI and have an MSI property set by the sys admin pre deployment that selects the right locale to deploy to his desktops.
I may although get this wrong, Matt can probably confirm on monday when he's back.
I don't think there's a way to build a single MSI for multiple locales. But this MSI is doing so little work that the only strings it has are the product vendor and brand name, so if we do want to use the multilocale full installer (which, to be entirely clear, is still theoretical right now), I think it would be possible to build an MSI for the neutral locale (so MSI will use the system locale for its UI) and have the admin set a property for the locale they want, as Romain described.

Also, to answer the other question from comment 6, I think we will have to build the MSI after the full installer is signed; the signature on the MSI will cover the full installer, but the installer executable itself being unsigned might still cause trouble.
Flags: needinfo?(mhowell)
> I don't think there's a way to build a single MSI for multiple locales.

Is that a limitation of MSI technology or are you referring to our releng limitations?
Flags: needinfo?(mhowell)
I think it's a limitation of the Windows Installer technology itself. I'm certain that it's at least a limitation of the WiX toolset.
Flags: needinfo?(mhowell)
Assignee: nobody → bugspam.Callek
Depends on: 1476980, 1476983
Blocks: 1493205
Keywords: leave-open
Pushed by jwood@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9840ad3f518a
Fix .zip fetch tasks on windows. r=tomprince
Depends on: 1501453
Attached file GitHub Pull Request
Comment on attachment 9021608 [details] [review]
GitHub Pull Request

Landing to production today in the 7.10.1 beetmoverscript bump.
Pushed by jwood@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/af173815a375
Beetmove .msi's for nightlies and releases. r=mtabara
Pushed by jwood@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9e811299a8e4
Add bouncer details for .msi for nightly and releases. r=mtabara
https://hg.mozilla.org/integration/autoland/rev/c2c914ab7300
Add bouncer check details in mozharness configs. r=mtabara
Flags: needinfo?(bugspam.Callek)
Keywords: leave-open
Pushed by jwood@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/062c4368399f
Add bouncer details for .msi for nightly and releases. r=mtabara
https://hg.mozilla.org/integration/autoland/rev/b66456c5c5fe
Add bouncer check details in mozharness configs. r=mtabara
https://hg.mozilla.org/mozilla-central/rev/062c4368399f
https://hg.mozilla.org/mozilla-central/rev/b66456c5c5fe
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla65

FWIW, bugzilla bots will start reporting issues associated with this bug because of brokne cron-bouncer jobs.

The cron-bouncer-checks share the same mozharness configuration as the actual bouncer-check from push graphs. During 65 train ride, we addeda new type of product (the msi stuff from this bug) so the mozharness configs have been enriched. However, in orrder to take the current products and versions, the script itself glances over to https://product-details.mozilla.org/1.0/firefox_versions.json to know which version is last. But there's a gap during RC week (between the time we merge beta to release with new potential configuration and the time we ship the new release) in which we may have conflicting values in product details vs in-tree configs.

In this case, the rel-bouncer-check shares the mozharness configs which are enriched with the msi installer stuff, but the product details still don't know of that and point to the current release train which is 64. Therefore all jobs of this nature will likely fail until we ship 65.

Since we rarely change the mozharness configs, it's a known automation bug that we can afford. If situation changes, we might need to find better solutions.

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