Closed Bug 1630809 Opened 4 years ago Closed 4 years ago

Support partner repacks which add attribution to Windows full installers

Categories

(Release Engineering :: Release Automation: Other, enhancement, P1)

Product:
Release Engineering
Component:
Release Automation: Other
Type:
enhancement

Tracking

(firefox82 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox82 --- fixed

People

(Reporter: nthomas, Assigned: nthomas)

References

Details

Attachments

(10 files)

GitHub Pull Request - shipit
49 bytes, text/x-github-pull-request
Details | Review
Bug 1630809 - python3 compatibility for off-cycle partner respins, typo fixes
47 bytes, text/x-phabricator-request
Details | Review
Bug 1630809 - only generate release-partner-repack tasks for enabled platforms
47 bytes, text/x-phabricator-request
Details | Review
Bug 1630809 - when downloading artifacts using fetch-content, optionally verify hash using chain-of-trust.json
47 bytes, text/x-phabricator-request
Details | Review
Bug 1630809 - check_if_partners_enabled() is only needed on the top kind for each partner branch
47 bytes, text/x-phabricator-request
Details | Review
Bug 1630809 - add initial support for partner attribution in release promotion
47 bytes, text/x-phabricator-request
Details | Review
Bug 1630809 - read attribution configuration from github
47 bytes, text/x-phabricator-request
Details | Review
Bug 1630809 - generate partner attribution task
47 bytes, text/x-phabricator-request
Details | Review
Bug 1630809 - generate beetmover tasks for partner attribution
47 bytes, text/x-phabricator-request
Details | Review
Bug 1630809 - add releng/partner/ private artifact scopes to gecko-t-signing-dev r=bhearsum
47 bytes, text/x-phabricator-request
Details | Review

A light weight way of producing partner repacks without needing to add any customizations inside the installer, just some attribution data added into the dummy cert. There's a python script on bug 1261140 which could be a good starting point, and there's go code for the stub attribution service.

Mike, do we know what the attribution data will look like ? We should probably watch out for text encoding issues, so I'm open to suggestions if we put a string in repack.cfg or take another approach.

Flags: needinfo?(mozilla)

What did the attribution data look like in the stub installer?

I'm thinking just a simple string or domain name:

foo.com

unitedinternet

Flags: needinfo?(mozilla)

(In reply to Mike Kaply [:mkaply] from comment #1)

What did the attribution data look like in the stub installer?

I'm not sure whether it's complete, but I think you can see some of the values used in tests here: 1

The description of this bug sounds like it only covers eliminating the distribution.ini files with nothing but a distribution id in them?

I'm mostly wondering whether I can use this to remove the attribution-like prefs in MozillaOnline repacks and reduce the many variants 2 into fewer ones (maybe just two, one for Windows and another one for macOS/Linux).

The description of this bug sounds like it only covers eliminating the distribution.ini files with nothing but a distribution id in them?

That the primary intent, but it could be more

I'm mostly wondering whether I can use this to remove the attribution-like prefs in MozillaOnline repacks and reduce the many variants 2 into fewer ones (maybe just two, one for Windows and another one for macOS/Linux).

I agree. If the only differences in your builds are the distribution ID, we should be able to use this.

Thanks for digging that test file up Hector. Here's another way to look at it - the keys which are parsed by Firefox. The stub attribution service will also force a value of '(not set') for source, medium, compaign, and content.

Perhaps we should ask someone who knows the existing namespaces used by those parameters, and how to co-operate with Telemetry, to determine what the new values might look like.

(In reply to Mike Kaply [:mkaply] from comment #3)

I'm mostly wondering whether I can use this to remove the attribution-like prefs in MozillaOnline repacks and reduce the many variants 2 into fewer ones (maybe just two, one for Windows and another one for macOS/Linux).

I agree. If the only differences in your builds are the distribution ID, we should be able to use this.

I'd been thinking of an either/or choice between existing repacks and attribution of vanilla, but this would need a combined mode that repacks then does one or more attributions ?

I'd been thinking of an either/or choice between existing repacks and attribution of vanilla, but this would need a combined mode that repacks then does one or more attributions ?

If that's the quickest solution, let's go with that. Longer term, it would be good to have both.

So I'm wondering if we're close to being able to do this yet?

I've got some partners that I want to work with and I would love to be able to use the new attribution code versus building a custom distro.

Work is well underway - I have a script to do the attribution and have been integrating that into the task generation for releases. Aiming to have it done in the next week.

Gecko patch set is tested against on mozilla-beta @ f1c7f75f5b6e (~80.0b7).
Example attribution config https://github.com/moz-releng-automation-stage/repack-manifests/blob/master/attribution_config.yml. More info in the docs contained in the patches.

Test release and respins at
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e139394c7317a080e637dcd70446c1f8d6bd3726
promote_firefox: ROT8kQUESlOf9x4fhzZQfA (expires 2020-09-08)
promote_firefox_partner_repack: B-kaIQYIRsOHYQvFHSqA6Q (expires 2020-09-17)
promote_firefox_partner_attribution: VHGqYjRWSnOOun1OZ9E4WA (expires 2020-09-17)

Installers to test (no official signing, click through UAC; check in about:telemetry after install, filter by 'attrib'):
win64: http://ftp.stage.mozaws.net/pub/firefox/candidates/80.0b8-candidates/build6/partner-repacks/sample/sample-001/v202008999999/win64/en-US/Firefox%20Setup%2080.0b8.exe
win32: http://ftp.stage.mozaws.net/pub/firefox/candidates/80.0b8-candidates/build6/partner-repacks/sample/sample-001/v202008999999/win32/en-US/Firefox%20Setup%2080.0b8.exe

Known issues

  • doesn't implement bouncer - ie creating version-specific products and locations, and updating aliases on shipping
  • doesn't implement mailing list to announce new releases (perhaps we have something already)
  • name collisions are possible between partner repacks and attribution, avoid that in configs to prevent files being overwritten by beetmover (eg sample/sample-001 above)
  • for respins, need to adjust braindump:releases-related/off-cycle-partner-respin.py to use new flavour for partner repack, add support for attribution
  • respin promotion tasks didn't show up on treeherder on try test

Prior to this patch the task graph would always include a release-partner-repack-<platform> task for all 6 platforms, regardless of what was specified in release_partner_config. This was particularly obvious in the off-cycle respin scenario when a single partner is repacked. By moving and reusing get_repack_ids_by_platform() it's easy to skip unneeded platforms.

Depends on D87723

This improves the integrity of downloads of upstream artifacts when using fetch-content. If verify-hash: True is set on the fetch config, then the chain-of-trust.json of the upstream is used to retieve the expected sha256 of the artifact, and this is checked.

Depends on D87724

If the partner repack task are already removed then there can be no downstreams to disable.

Depends on D87725

Renames the release_enable_partners parameter to release_enable_partner_repack, and adds release_enable_partner_attribution for attribution. This it to provide support for disabling them independently in main releases, and in respins.
Adds docs for attribution, update docs for repacks.
Hardwire values for the enable params for the respin flavors, other wise read from the input (defaulting to on in promotion, off otherwise).
Fixes up the rebuild-kinds for partner repacks so that they reflect the current set, although the top level may be all that is needed.

Depends on D87726

The partner attribution config is stored in the same repository as the repo manifest for partner repacks, but all in attribution_config.yml instead of default.xml. This extends the existing support for using the Github API to read files to retrieve and process the attribution config.

Depends on D87727

A single task is created to do all partner attributions. The partner_attribution transform processes the configuration into an environment variable for the tools/attribution/attribute.py script to use. This is quite verbose so a large number of configurations may cause problems.

Applies the same priority modification to attribution tasks as to partner repacks, to not impede the main part of the graph.

Depends on D87728

This is a fork of the release-partner-repack-beetmover kind and transform. It's modified to cope with having one upstream task with many partner builds, rather than a many beetmover tasks dealing with a single config-platform-locale combination.

Depends on D87729

Mike, should we review and land this as-is, or hold off til we can improve it? Status in comment 9.

Flags: needinfo?(mozilla)
Assignee: nrthomas → nobody

I'm worried that if we don't check it in, it will just get lost in the shuffle.

Based on what Nick said in that comment, it should basically work, right?

Flags: needinfo?(mozilla)
Assignee: nobody → nrthomas
Status: NEW → ASSIGNED

It looks like we still need to create a prod attribution_config.yml in repack-manifests. Mike, is this on your list?

Flags: needinfo?(mozilla)

It is now :).

Flags: needinfo?(mozilla)

These patches all got rebased onto 82.0 @ 61ed3192760a, unfortunately this screws up some of the interdiffs.

So I think the first one would look like this:

default:
medium: distribution
source: mozilla
softonic:
softonic-004:
campaign: softonic
content: softonic-004
upstream: vanilla
platforms:
- win64
- win32
- mac
locales:
- en-US
- es-AR
- es-CL
- es-MX
- es-ES
upload_to_candidates: true

I don't 100% know YAML, this is based of the spec nthomas put together:

Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/ci/ci-configuration/rev/8be446357e23
add releng/partner/ private artifact scopes to gecko-t-signing-dev r=bhearsum

mkaply, I ended up changing the format a bit to avoid repeated values, and didn't implement upstream support, more info in patch. Notably configs is a list of dictionaries, rather than nested dictionaries.

I'd translate your config to this:

defaults:
  medium: distribution
  source: mozilla
configs:
- campaign: softonic
  content: softonic-004
  locales:
    - en-US
    - es-AR
    - es-CL
    - es-MX
    - es-ES
  platforms:
    - win64-shippable
    - win32-shippable
  upload_to_candidates: true

The platforms match the taskcluster values (which differs from the values used in partner repack configs) and I dropped the mac that snuck in there. win64-aarch64-shippable is the other possible value; it should work fine although technically I haven't tested that.

Belatedly realized that when upload_to_candidates is enabled then directories like

http://ftp.stage.mozaws.net/pub/firefox/candidates/82.0b10-candidates/build2/partner-repacks/sample/sample-001/v1/win64/en-US/
                                                                             ^^^^^^^^^^^^^^^

are used. As a followup, beetmover could be tweaked to use .../partner-attributions/... for the attribution case, which would avoid any name collisions leading to files being overwritten.

Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b3746502e227
python3 compatibility for off-cycle partner respins, typo fixes r=aki
https://hg.mozilla.org/integration/autoland/rev/d3d841cd14f3
only generate release-partner-repack tasks for enabled platforms r=aki
https://hg.mozilla.org/integration/autoland/rev/ad5e4caa3291
when downloading artifacts using fetch-content, optionally verify hash using chain-of-trust.json r=aki
https://hg.mozilla.org/integration/autoland/rev/d6652114cac3
check_if_partners_enabled() is only needed on the top kind for each partner branch r=aki
https://hg.mozilla.org/integration/autoland/rev/2fa2deb5c993
add initial support for partner attribution in release promotion r=aki
https://hg.mozilla.org/integration/autoland/rev/4b4d50e0b1bf
read attribution configuration from github r=aki
https://hg.mozilla.org/integration/autoland/rev/04628c1f98e9
generate partner attribution task r=aki
https://hg.mozilla.org/integration/autoland/rev/afb5df61943a
generate beetmover tasks for partner attribution r=aki
Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9e38cbdb7b96
python3 compatibility for off-cycle partner respins, typo fixes r=aki
https://hg.mozilla.org/integration/autoland/rev/7efb583e8d11
only generate release-partner-repack tasks for enabled platforms r=aki
https://hg.mozilla.org/integration/autoland/rev/f11d861827cd
when downloading artifacts using fetch-content, optionally verify hash using chain-of-trust.json r=aki
https://hg.mozilla.org/integration/autoland/rev/cb58bfed5420
check_if_partners_enabled() is only needed on the top kind for each partner branch r=aki
https://hg.mozilla.org/integration/autoland/rev/2683d8570ef8
add initial support for partner attribution in release promotion r=aki
https://hg.mozilla.org/integration/autoland/rev/6eae524a8eec
read attribution configuration from github r=aki
https://hg.mozilla.org/integration/autoland/rev/e90a86c44d52
generate partner attribution task r=aki
https://hg.mozilla.org/integration/autoland/rev/0015c6400e72
generate beetmover tasks for partner attribution r=aki

Looks like this is fixed with scopes.

Flags: needinfo?(aki)
Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/18eb153a6d7c
Port bug 1630809 - Update partner-urls for new configuration syntax. rs=bustage-fix

Hi Mike & Nick:

I understand the landed automation patches don't support my usecase in comment 2 yet. But since the attribution code format for partners is now finalized, would it be okay for me to start manually adding attributions like medium=distribution&source=mozilla&campaign=mozillaonline&content=qihoo to the generated China repacks with the partner_attribution.py script?

Thanks.

(In reply to Hector Zhao [:hectorz] from comment #33)

Hi Mike & Nick:

I understand the landed automation patches don't support my usecase in comment 2 yet. But since the attribution code format for partners is now finalized, would it be okay for me to start manually adding attributions like medium=distribution&source=mozilla&campaign=mozillaonline&content=qihoo to the generated China repacks with the partner_attribution.py script?

Thanks.

We just got this landed, and don't have anything built with it enabled yet. It won't be ready for use on the beta channel until 80.0b8, and 81 on release.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #34)

We just got this landed, and don't have anything built with it enabled yet. It won't be ready for use on the beta channel until 80.0b8, and 81 on release.

Hi Ben,

What I'm trying to do is not really covered by the recently landed patches, please refer to comment 2 - comment 5 above for more context.

I gave it a try anyway, and turns out it's not possible to add attribution code to partner repacks, unless they're switched to autograph_authenticode_stub, similar to vanilla full installers in bug 1630154.

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

Attachment

General

Creator:
Created:
Updated:
Size: