Sign language packs via Autograph instead of AMO.
Categories
(Release Engineering :: Release Automation, enhancement)
Tracking
(firefox70 fixed)
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: Callek, Assigned: Callek)
References
(Regression)
Details
Attachments
(8 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1566298 - Block explicit scheduling for the release in balrog on AMO langpack pushing. r=mtabara
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
By relying on AMO to do language pack signing we introduced a SPOF onto the release process that is both a long tail as well as a potential issue in terms of finding humans who can help fix the process should AMO be broken for a given l10n changeset.
We treat the in-tree files for L10n as "we expect these to be valid" so we don't need the AMO added validations on them to block releases.
Assignee | ||
Comment 1•6 years ago
|
||
Hey Ritu,
So I have a question that is best on relman, imo.
For this work, should I leave the "AMO" shipping as "let it happen, if it fails sheriffs should notice" or "let it block marking the release as shipped..."
I can see arguments for both. I'm happy to join a zoom meeting with you or the team to discuss further.
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
Assignee | ||
Comment 4•6 years ago
|
||
This patch's main goal is to help ease diffs between other parts of this set.
Assignee | ||
Comment 5•6 years ago
|
||
Comment 6•6 years ago
•
|
||
Justin and I had a good zoom discussion about this.
-
My understanding is that if the AMO shipping of langpacks fail and there is a major version update (e.g. 68.0b1 -> 69.0b1 or 68.0.1 -> 69.0), beta/release end-users using a Firefox client with a langpack will be reverted to EN-US Firefox client. This would be a terrible experience for an l10n end-user.
-
I was also told that the likelihood of an AMO upload failure (during releng build promotion workflow) is rare, a handful times a year.
Given 1) and 2), I would like to recommend that we block pushing a release to beta/release channel if the AMO upload fails.
As Justin suggested, if AMO upload fails, it is OK for releng tasks to push build to cdn-test for QA testing but block the balrog sign-off rule creation.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 7•6 years ago
|
||
This was due to conversation between myself and :ritu as relman over, documented
at https://bugzilla.mozilla.org/show_bug.cgi?id=1566298#c6
Depends on D37832
Assignee | ||
Comment 9•6 years ago
|
||
I pushed the stack except (to be reviewed) D37832 so I could see this work in production on m-c in the meantime, the remaining patch only affects releases anyway.
Comment 10•6 years ago
|
||
bugherder |
Comment 11•6 years ago
|
||
Backed out for nightly-l10n-signing bustages
Backout link: https://hg.mozilla.org/integration/autoland/rev/0f9e8c785bee1e2dde93d486713265f4f36fb262
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=260776647&repo=mozilla-central&lineNumber=33
Assignee | ||
Comment 12•6 years ago
|
||
Aki, can you help make sure that the secrets are properly in place re: c#11 - once they are I'll reland the stack.
![]() |
||
Comment 13•6 years ago
|
||
Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/0f9e8c785bee
Comment 14•6 years ago
|
||
Ah. I added it to the end of the file, after omnija, but failed to remember that there are both release and nightly configs, so that only added it to the release configs. Added to the nightly configs as well, and ran a test run of the above failing l10n task.
Comment 15•6 years ago
|
||
Comment 16•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/569f2c9767ec
https://hg.mozilla.org/mozilla-central/rev/788314e6953a
https://hg.mozilla.org/mozilla-central/rev/e777273b4aa5
https://hg.mozilla.org/mozilla-central/rev/aa829090c7bb
https://hg.mozilla.org/mozilla-central/rev/3fdd496723be
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 17•6 years ago
|
||
Comment 18•6 years ago
|
||
Comment 19•6 years ago
|
||
bugherder |
Comment 20•5 years ago
|
||
Comment 21•5 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/2c2cb0df95176e9a72e76e679ad135d66eb6e500 , still needs "downlifting" to m-c
Comment 22•5 years ago
|
||
Aki, langpack is failing on the fix https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&searchStr=langpack&selectedJob=263635813 with another error: https://tools.taskcluster.net/groups/M_5Ka6RQSN2DDiMSmVTe8w/tasks/arqpOHXYTMem5eRU13wlNg/runs/0/logs/public%2Flogs%2Fchain_of_trust.log
Comment 23•5 years ago
|
||
(In reply to Razvan Maries from comment #22)
Aki, langpack is failing on the fix https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&searchStr=langpack&selectedJob=263635813 with another error: https://tools.taskcluster.net/groups/M_5Ka6RQSN2DDiMSmVTe8w/tasks/arqpOHXYTMem5eRU13wlNg/runs/0/logs/public%2Flogs%2Fchain_of_trust.log
seems like we knew about moving target.langpack.xpi out of en-US
based on: https://hg.mozilla.org/releases/mozilla-beta/rev/b1eacaaab2581c4b2f2068b5543a9f988ffd69a8
however, we are still hitting issues where beetmover expects target.langpack.xpi upstream_artifacts to live in 'en-US'. Maybe this block pointed out by nick was missed? https://hg.mozilla.org/releases/mozilla-beta/file/default/taskcluster/taskgraph/transforms/release_beetmover_signed_addons.py#l144
Assignee | ||
Comment 24•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 25•5 years ago
|
||
Comment 26•5 years ago
|
||
bugherder |
Updated•3 months ago
|
Description
•