Partner attribution

In contrast to Partner repacks, attributed builds only differ from the normal Firefox builds by the adding a string in the dummy windows signing certificate. We support doing this for full installers but not stub. The parameters of the string are carried into the telemetry system, tagging an install into a cohort of users. This a lighter weight process because we don’t repackage or re-sign the builds.

Parameters & Scheduling

Partner attribution uses a number of parameters to control how they work:

• release_enable_partner_attribution

• release_partner_config

• release_partner_build_number

• release_partners

The enable parameter is a boolean, a simple on/off switch. We set it in shipit’s is_partner_enabled() when starting a release. It’s true for Firefox betas >= b8 and releases, but otherwise false, the same as partner repacks.

release_partner_config is a dictionary of configuration data which drives the task generation logic. It’s usually looked up during the release promotion action task, using the Github GraphQL API in the get_partner_config_by_url() function, with the url defined in taskcluster/config.yml.

release_partner_build_number is an integer used to create unique upload paths in the firefox candidates directory, while release_partners is a list of partners that should be attributed (i.e. a subset of the whole config). Both are intended for use when respinning a partner after the regular Firefox has shipped. More information on that can be found in the RelEng Docs.

release_partners is shared with partner repacks but we don’t support doing both at the same time.

Configuration

This is done using an attribution_config.yml file which next lives to the default.xml used for partner repacks. There are no repos for each partner, the whole configuration exists in the one file because the amount of information to be tracked is much smaller.

An example config looks like this:

defaults:
    medium: distribution
    source: mozilla
configs:
    -   campaign: sample
        content: sample-001
        locales:
        - en-US
        - de
        - ru
        platforms:
        - win64-shippable
        - win32-shippable

The four main parameters are medium, source, campaign, content, of which the first two are common to all attributions. The combination of campaign and content should be unique to avoid confusion in telemetry data. They correspond to the repo name and sub-directory in partner repacks, so avoid any overlap between values in partner repacks and atrribution. The optional parameters of variation, and experiment may also be specified.

Non-empty lists of locales and platforms are required parameters (NB the -shippable suffix should be used on the platforms).

The Firefox installers are uploaded into the candidates directory.

Repacking process

Attribution only has two kinds:

• attribution - add attribution code to the regular builds

• beetmover - move the files to a partner-specific destination

Attribution

• kinds: release-partner-attribution

• platforms: Any Windows, runs on linux

• upstreams: repackage-signing repackage-signing-l10n

There is one task, calling out to python/mozrelease/mozrelease/attribute_builds.py.

It takes as input the repackage-signing and repackage-signing-l10n artifacts, which are all target.exe full installers. The ATTRIBUTION_CONFIG environment variable controls the script. It produces more target.exe installers.

The size of ATTRIBUTION_CONFIG variable may grow large if the number of configurations increases, and it may be necessary to pass the content of attribution_config.yml to the script instead, or via an artifact of the promotion task.

Beetmover

• kinds: release-partner-attribution-beetmover

• platforms: N/A, scriptworker

• upstreams: release-partner-attribution

Moves and renames the artifacts to their public location in the candidates directory.

Each task will have the project:releng:beetmover:action:push-to-partner and project:releng:beetmover:bucket:release scopes. There’s a partner-specific code path in beetmoverscript.