Within RelEng, there are currently three types of interactions with bouncer.
This step is required for all types of in-tree gecko-based releases. What this
means specifically is letting bouncer know that there are new products incoming.
Keep in mind that bouncer database is consumed by Mozilla's official
downloads page to serve all types of
installers. Amongst those there are the main installers for new users (e.g. exe, dmg, etc)
but also the updates that are queried from Balrog. Bouncer must know of all these
artifacts' existence in order to serve them.
For example, whenever we build a (e.g.)Firefox beta X release,
bouncer must first know what the associated products are for this particular release.
Those could include but are not limited to the following:
X-CompleteX-Partial-YX-Partial-ZX-Partial-TX-SSLX-stub- ... (where
Y,ZandTare previous versions used for partials).
While the SSL files are going to be served in the downloads page for consumers,
the rest of the artifacts are going to be queried from Balrog in urls like this.
To conclude, bouncer needs to have in its database all of these products.
Within release promotion, this step is called release-bouncer-submission and
it happens within the promotion phase and is among the first tasks that run.
All of the above are separate products from bouncer's standpoint, each
defined with its own entry, set of locales, properties and such. And each of the
products is then associated with certain locations on where to retrieve those
files from S3.
bouncer_submission behavior in bouncerscript handles this behavior and consists
of two operations:
- submit each of these
productsas entities in bouncer database - submit associated
locationsfor each of these products
For example, the specific Firefox-63.0b9-Complete product in bouncer looks something like:
while its associated locations look something like:
This step is required for all types of in-tree gecko-based releases. What this
means specifically is giving bouncer a shortcut way to point to most recent releases
for a particular channel/product. The aliases address solely the main installers that
new users are supposed to download, unpack and install their Mozilla products with. (e.g. exe, dmg, etc)
Simply stating the bouncer aliases, these are nothing more than a mapping
that associates a particular alias to the latest product that has been shipped and approved by RelEng, RelMan
and QA for that particular channel.
Within release promotion, this step is called release-bouncer-aliases and
it happens within the ship phase.
bouncer_aliases behavior in bouncerscript handles this behavior and consists
of one simple operation:
- update each
aliaswith the corresponding latestproduct
For example, a subset of aliases looks something like:
The aforementioned aliases are particularly useful to serve the installers on
the release channel, but what happens on mozilla-central? On trunk we don't have
multiple phases within a release, nor we have QA. We ship as soon as we build, sign,
transfer to S3 and serve updates. For that particular reason, historically, there
have been added a couple of products (at first glance, they can be confused over
as being aliases but they are not! they are simply products as explained above).
Basically the following products have been added, each with its own set of locales,
properties and such, in the same way bouncer_submission automates things per release.
The only difference is that these were added only once, at one time in the past
and have just been updated ever since.
firefox-nightly-latestfirefox-nightly-latest-sslfirefox-nightly-latest-l10nfirefox-nightly-latest-l10n-ssl
Once the products have manually been added, for each of these products, a location per
platform has been added to point to the installers's S3 finding. Since
nightlies are served from the latest directories, these entries have been mostly the same
for years. With one particular exception that is the version we shipped. Every 6-8 weeks,
as part of the mergeduty, we used to bump the version for each of these locations
for each of these products. That's been fully automated recently and runs as part of
the nightly graphs every day.
bouncer_locations behavior in bouncerscript handles this behavior and consists
of one simple operation:
- for each of the aforementioned
products, update eachlocationby bumping its version
For example, updating all locations for one of the products looks something like:
