From 6bf0a5cb5034a7e684dcc3500e841785237ce2dd Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 19:32:43 +0200 Subject: Adding upstream version 1:115.7.0. Signed-off-by: Daniel Baumann --- taskcluster/docs/partner-attribution.rst | 121 +++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 taskcluster/docs/partner-attribution.rst (limited to 'taskcluster/docs/partner-attribution.rst') diff --git a/taskcluster/docs/partner-attribution.rst b/taskcluster/docs/partner-attribution.rst new file mode 100644 index 0000000000..058000fe4e --- /dev/null +++ b/taskcluster/docs/partner-attribution.rst @@ -0,0 +1,121 @@ +Partner attribution +=================== +.. _partner attribution: + +In contrast to :ref:`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/ci/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: + +.. code-block:: yaml + + defaults: + medium: distribution + source: mozilla + configs: + - campaign: sample + content: sample-001 + locales: + - en-US + - de + - ru + platforms: + - win64-shippable + - win32-shippable + upload_to_candidates: true + +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). + +``upload_to_candidates`` is an optional setting which controls whether the Firefox installers +are uploaded into the `candidates directory `_. +If not set the files are uploaded to the private S3 bucket for partner builds. + + +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 necesssary 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 +`_, or a private S3 bucket. There is one task +for public artifacts and another for private. + +Each task will have the ``project:releng:beetmover:action:push-to-partner`` scope, with public uploads having +``project:releng:beetmover:bucket:release`` and private uploads using +``project:releng:beetmover:bucket:partner``. There's a partner-specific code path in +`beetmoverscript `_. -- cgit v1.2.3