Firefox Snap Packaging¶
This page explains interactions between Firefox and Snap packaging format.
Where is the upstream¶
The code reference itself is mozilla-central, but the packaging is being worked within the Canonical’s firefox-snap repository.
This packaging includes a few more bits and dependencies, including compiler. It will also re-download the mercurial repository: this is on purpose.
Where to report bugs¶
All bugs should be reported to Bugzilla’s Third Party Packaging
component,
and marked as blocking snap
meta-bug.
Build process¶
While there is an existing repackage
task,
is currently is no up-to-date and it is not usable from mach
(work is being
tracked in for this),
so unfortunately the only way to work right now is a full rebuild using
upstream tooling.
The following steps should be enough, assuming you have properly setup:
snapcraft
(see quickstart doc)
LXD
(see providers doc)
While the documentation still refers to Multipass, the Firefox Snap and its dependency had some requirements that made it better suited to use LXD.
When performing the checkout, please keep in mind the branch mapping:
edge is our nightly
beta is our beta
stable is our release
esr is our esr
$ git clone https://github.com/canonical/firefox-snap --branch BRANCH
$ snap run snapcraft
You should end up after some time with two files: firefox-XXX.snap
and
firefox-XXX.debug
. The first one is the package you will want to snap
install
while the second one holds your debugging symbols.
You can then install the package:
$ sudo snap install --name firefox --dangerous ./path/to/firefox-XXX.snap
If you want to have parallel installs, then you can change the –name firefox
to something else. This will be the name you use for snap run
installed-name
, e.g., --name firefox_nightly
will require you to run
snap run firefox_nightly
.
Snap has a notion of plugs and slots, and some gets automatically connected
in various ways, including depending on the Snap Sore
itself, and if you
manually install as firefox
it should reuse them (but you might do bad
things with your profile). If you install using another name, then the Snap
Store
automatic connection will not happen and this can result in a broken
state. Inspecting snap connections firefox
using a store-installed snap
should get your an accurate list that you can replicate.
What CI coverage¶
Currently, there are upstream-like builds on treeherder. They are scheduled as a cron task daily and includes:
building opt/debug versions of the snap
building them on all branches
running a few selenium-based tests
The build definitions are based on docker.
It should be noted that for the moment, all tasks needs to run under docker. However, this setup is not working for Snap since it interacts with SystemD which does not work under Docker. This is why the installation is handled by the install-snap script rather than plain sudo snap install, and also why we need to run snap in destructive mode (which is fine since we are within a docker container). This does not apply to the tests case which relies on newly-available wayland virtual machines.
Outside the build oddities because of the setup, it should be noted that those builds are as close as possible to upstream. This means:
the mozilla-central hash they run against is not matching the source code it builds from, and one should inspect the build log to see the mercurial clone step
it builds using the clang build within the snap definition
The tests are defined within the docker subdirectory. They are using Selenium because this is what was used by pre-existing tests ran on GitHub Actions from upstream.
Their coverage is ensuring that we get a basic working browser out of builds. It includes some tests that previously were manually ran by QA.
How to hack on try¶
Build and test tasks can be explored via mach try fuzzy --full
by searching
for 'snap 'upstream
. There is a bit of hacking for try to make sure we
actually don’t re-download the mercurial repo and directly reuse the clone
generated by run-task, handled in the run.sh script.
So pushing to try is basically just:
$ mach try fuzzy --full -q "'snap 'upstream 'try"
Because of the build process, a full opt build will take around 1h45-2h while a debug build will be around 60 minutes, the difference coming from the use of PGO on opt builds.
If you need to reuse a package from the Snap Store or from the latest
mozilla-central or a specific successful build, you can use USE_SNAP_FROM_STORE_OR_MC
en
variable ; setting it to store
will download from the Snap Store (warning:
no debug builds on the Snap Store, so whatever debug
variants we have will
be an opt
build in fact), and setting to a TaskCluster index value will
download from the index. Set it to latest
if you want latest, or explore
the TaskCluster index for others. Any try
will be pulled from latest
nightly
while others will be fetched from their respective branches.
How to hack locally¶
After a successful build, you can also build a Snap by performing a repackaging
using the mach repackage snap
tool. This requires a snapcraft
working
installation relying on LXD
, which installation steps are
documented upstream.