Publish ARM64/aarch64 Windows MSIX packages to archive.mozilla.org
Categories
(Release Engineering :: Release Automation: Uploading, enhancement)
Tracking
(firefox126 fixed, firefox127 fixed)
People
(Reporter: nalexander, Assigned: gbrown)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-beta+
|
Details | Review |
Following up on Bug 1731140, I see Nightly packages being built, for example around https://treeherder.mozilla.org/jobs?repo=mozilla-central&revision=79551503d77c8353439905d86ec3033546f0c874&searchStr=repackage&selectedTaskRun=WiJuBxYBR1KCIfUT9Q1aag.0 but it's not clear that the MSIX packages are getting pushed to archive.mozilla.org (let alone the store). In particular, I don't see anything ARM64-y in https://archive.mozilla.org/pub/firefox/nightly/2024/04/2024-04-09-09-39-00-mozilla-central/.
Per :bhearsum's comment:
- We get signing for free because https://searchfox.org/mozilla-central/source/taskcluster/ci/repackage-signing-shippable-l10n-msix/kind.yml is downstream of repackage-shippable-l10n-msix, and has no platform conditions.
- Nightly publishing to archive is handled by https://searchfox.org/mozilla-central/source/taskcluster/ci/beetmover-repackage/kind.yml, which already has the right kind-dependencies and platforms specified
- Store publishing is handled by https://searchfox.org/mozilla-central/source/taskcluster/ci/release-msix-push/kind.yml, which similarly has the right kind-dependencies, and no platform conditions.
Digging deeper, I see a functional ARM64 beetmover task at https://treeherder.mozilla.org/jobs?repo=mozilla-central&revision=79551503d77c8353439905d86ec3033546f0c874&searchStr=beetmover-repackage&selectedTaskRun=P7WzzmmUQ1uqMXPtPqtCng.0, but there's no mention of target.installer.msix
in there. So something somewhere needs to tell this task to handle MSIX packages.
:bhearsum, can you guide?
Reporter | ||
Updated•7 months ago
|
Comment 1•7 months ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #0)
Following up on Bug 1731140, I see Nightly packages being built, for example around https://treeherder.mozilla.org/jobs?repo=mozilla-central&revision=79551503d77c8353439905d86ec3033546f0c874&searchStr=repackage&selectedTaskRun=WiJuBxYBR1KCIfUT9Q1aag.0 but it's not clear that the MSIX packages are getting pushed to archive.mozilla.org (let alone the store). In particular, I don't see anything ARM64-y in https://archive.mozilla.org/pub/firefox/nightly/2024/04/2024-04-09-09-39-00-mozilla-central/.
Per :bhearsum's comment:
- We get signing for free because https://searchfox.org/mozilla-central/source/taskcluster/ci/repackage-signing-shippable-l10n-msix/kind.yml is downstream of repackage-shippable-l10n-msix, and has no platform conditions.
- Nightly publishing to archive is handled by https://searchfox.org/mozilla-central/source/taskcluster/ci/beetmover-repackage/kind.yml, which already has the right kind-dependencies and platforms specified
- Store publishing is handled by https://searchfox.org/mozilla-central/source/taskcluster/ci/release-msix-push/kind.yml, which similarly has the right kind-dependencies, and no platform conditions.
Digging deeper, I see a functional ARM64 beetmover task at https://treeherder.mozilla.org/jobs?repo=mozilla-central&revision=79551503d77c8353439905d86ec3033546f0c874&searchStr=beetmover-repackage&selectedTaskRun=P7WzzmmUQ1uqMXPtPqtCng.0, but there's no mention of
target.installer.msix
in there. So something somewhere needs to tell this task to handle MSIX packages.:bhearsum, can you guide?
Ah, my bad. I forgot about the nightly and release manifests that taskgraph consumes. Updating those should do the trick.
It looks like other changes will be needed if we want to make them available through Bouncer as well (which I presume we do). See https://phabricator.services.mozilla.com/D126949 and https://phabricator.services.mozilla.com/D126950 for what we do for x86/x64.
Reporter | ||
Comment 2•7 months ago
|
||
Updated•7 months ago
|
Reporter | ||
Comment 3•7 months ago
|
||
I'm scoping this down to just archive.mozilla.org and the download bouncer; let's handle publishing to the Microsoft Store separately.
Reporter | ||
Comment 4•6 months ago
|
||
bhearsum: I recall the last word being that we'd get releng to push this across the line before revisiting publishing to the Microsoft Store. Can we get an assignee that is not me?
Comment 5•6 months ago
|
||
Apologies for the delay - Johan is helping getting this assigned.
Comment 6•6 months ago
|
||
Discussed over Slack. :gbrown will provide support.
Assignee | ||
Updated•6 months ago
|
Assignee | ||
Comment 7•6 months ago
|
||
Assignee | ||
Comment 8•6 months ago
|
||
See discussion in D207087: We need to archive to a.m.o first, then revisit bouncer.
Assignee | ||
Updated•6 months ago
|
Assignee | ||
Comment 9•6 months ago
|
||
I ran a staging release against a patch that only adds win64-aarch64 to beetmover (no bouncer changes) and release-bouncer-sub-firefox failed
https://treeherder.mozilla.org/jobs?repo=try&revision=cc2641cc74b575157c52b45cd603abc08c2a1cf3
https://treeherder.mozilla.org/logviewer?job_id=455765954&repo=try&lineNumber=432
2024-04-25 03:45:05,179 - bouncerscript.utils - INFO - Calling location_show?product=Firefox-127.0b1-msix-SSL with data: {}
2024-04-25 03:45:05,179 - bouncerscript.utils - INFO - Performing a GET request to https://dev.bounceradmin.nonprod.webservices.mozgcp.net/api/location_show?product=Firefox-127.0b1-msix-SSL with kwargs {'timeout': 60}
2024-04-25 03:45:05,258 - bouncerscript.utils - INFO - Server response: <?xml version="1.0" encoding="utf-8"?><locations><product id="34684" name="Firefox-127.0b1-msix-SSL"><location id="144728" os="win">/firefox/releases/127.0b1/win32/multi/Firefox%20Setup%20127.0b1.msix</location><location id="144729" os="win64">/firefox/releases/127.0b1/win64/multi/Firefox%20Setup%20127.0b1.msix</location><location id="144730" os="win64-aarch64">/firefox/releases/127.0b1/win64-aarch64/multi/Firefox%20Setup%20127.0b1.msix</location></product></locations>
2024-04-25 03:45:05,260 - bouncerscript.utils - DEBUG - Locations info: [{'os': 'win', 'id': '144728', 'path': '/firefox/releases/127.0b1/win32/multi/Firefox%20Setup%20127.0b1.msix'}, {'os': 'win64', 'id': '144729', 'path': '/firefox/releases/127.0b1/win64/multi/Firefox%20Setup%20127.0b1.msix'}, {'os': 'win64-aarch64', 'id': '144730', 'path': '/firefox/releases/127.0b1/win64-aarch64/multi/Firefox%20Setup%20127.0b1.msix'}]
2024-04-25 03:45:05,261 - scriptworker.client - ERROR - Failed to run async_main
Traceback (most recent call last):
File "/app/lib/python3.9/site-packages/scriptworker/client.py", line 205, in _handle_asyncio_loop
await async_main(context)
File "/app/lib/python3.9/site-packages/bouncerscript/script.py", line 166, in async_main
await action_map[context.action](context)
File "/app/lib/python3.9/site-packages/bouncerscript/script.py", line 70, in bouncer_submission
check_locations_match(locations_paths, pr_config["paths_per_bouncer_platform"])
File "/app/lib/python3.9/site-packages/bouncerscript/task.py", line 126, in check_locations_match
raise ScriptWorkerTaskException("Bouncer entries are corrupt")
scriptworker.exceptions.ScriptWorkerTaskException: Bouncer entries are corrupt
Is that because of my previous staging release against D207087? If so, what can I do to "clean up" staging? (or should I just move on from 127.0b1?)
Assignee | ||
Comment 10•6 months ago
|
||
Nevermind: Experiments confirmed that the error is associated with the 127.0b1 release and not caused by the current patch.
Comment 11•6 months ago
|
||
Comment 12•6 months ago
|
||
bugherder |
Comment 13•6 months ago
|
||
(In reply to Geoff Brown [:gbrown] from comment #9)
I ran a staging release against a patch that only adds win64-aarch64 to beetmover (no bouncer changes) and release-bouncer-sub-firefox failed
https://treeherder.mozilla.org/jobs?repo=try&revision=cc2641cc74b575157c52b45cd603abc08c2a1cf3
https://treeherder.mozilla.org/logviewer?job_id=455765954&repo=try&lineNumber=4322024-04-25 03:45:05,179 - bouncerscript.utils - INFO - Calling location_show?product=Firefox-127.0b1-msix-SSL with data: {} 2024-04-25 03:45:05,179 - bouncerscript.utils - INFO - Performing a GET request to https://dev.bounceradmin.nonprod.webservices.mozgcp.net/api/location_show?product=Firefox-127.0b1-msix-SSL with kwargs {'timeout': 60} 2024-04-25 03:45:05,258 - bouncerscript.utils - INFO - Server response: <?xml version="1.0" encoding="utf-8"?><locations><product id="34684" name="Firefox-127.0b1-msix-SSL"><location id="144728" os="win">/firefox/releases/127.0b1/win32/multi/Firefox%20Setup%20127.0b1.msix</location><location id="144729" os="win64">/firefox/releases/127.0b1/win64/multi/Firefox%20Setup%20127.0b1.msix</location><location id="144730" os="win64-aarch64">/firefox/releases/127.0b1/win64-aarch64/multi/Firefox%20Setup%20127.0b1.msix</location></product></locations> 2024-04-25 03:45:05,260 - bouncerscript.utils - DEBUG - Locations info: [{'os': 'win', 'id': '144728', 'path': '/firefox/releases/127.0b1/win32/multi/Firefox%20Setup%20127.0b1.msix'}, {'os': 'win64', 'id': '144729', 'path': '/firefox/releases/127.0b1/win64/multi/Firefox%20Setup%20127.0b1.msix'}, {'os': 'win64-aarch64', 'id': '144730', 'path': '/firefox/releases/127.0b1/win64-aarch64/multi/Firefox%20Setup%20127.0b1.msix'}] 2024-04-25 03:45:05,261 - scriptworker.client - ERROR - Failed to run async_main Traceback (most recent call last): File "/app/lib/python3.9/site-packages/scriptworker/client.py", line 205, in _handle_asyncio_loop await async_main(context) File "/app/lib/python3.9/site-packages/bouncerscript/script.py", line 166, in async_main await action_map[context.action](context) File "/app/lib/python3.9/site-packages/bouncerscript/script.py", line 70, in bouncer_submission check_locations_match(locations_paths, pr_config["paths_per_bouncer_platform"]) File "/app/lib/python3.9/site-packages/bouncerscript/task.py", line 126, in check_locations_match raise ScriptWorkerTaskException("Bouncer entries are corrupt") scriptworker.exceptions.ScriptWorkerTaskException: Bouncer entries are corrupt
Is that because of my previous staging release against D207087? If so, what can I do to "clean up" staging? (or should I just move on from 127.0b1?)
I have some thoughts in https://bugzilla.mozilla.org/show_bug.cgi?id=1893627#c1 but the tl;dr version is that bouncerscript is very strict about what it expects (to avoid accidents in production, I guess). There's some precedent for relaxing those restrictions on Try. In this particular case, I think it's fine to just let it fail until this work lands, and makes it into the simulations.
Assignee | ||
Comment 14•6 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D208539
Updated•6 months ago
|
Comment 15•6 months ago
|
||
beta Uplift Approval Request
- User impact if declined: aarch64 msix not copied to a.m.o; delays to aarch64 bouncer support
- Code covered by automated testing: no
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: check that aarch64 msix is copied to a.m.o alongside win32 and win64
- Risk associated with taking this patch: low risk
- Explanation of risk level: just copies the aarch64 msix to a.m.o
- String changes made/needed: none
- Is Android affected?: no
Updated•6 months ago
|
Comment 16•6 months ago
|
||
uplift |
Comment 17•6 months ago
|
||
Backed out of beta, uplifted in error.
This has an open regression Bug 1893677
Backout: https://hg.mozilla.org/releases/mozilla-beta/rev/48b546312eb48ce7b48e3ee20712d8041838c458
Comment 18•6 months ago
|
||
Comment on attachment 9398859 [details]
Bug 1890607 - Publish Windows aarch64 msix to archive.mozilla.org
Rejecting beta upllift request due to regressions in central linked to this patch
Assignee | ||
Comment 19•6 months ago
|
||
Sorry for the confusion! Actually, that regression is not related to this bug. Can we go ahead with the beta uplift?
Comment 20•6 months ago
|
||
Sure, I can take this in a later push.
This bug is in a leave-open state, could this be resolved since a patch has landed in central?
Anything else needed could be tracked under a separate bug. It adds complexity to tracking otherwise.
Updated•6 months ago
|
Assignee | ||
Comment 21•6 months ago
|
||
(In reply to Donal Meehan [:dmeehan] from comment #20)
This bug is in a leave-open state, could this be resolved since a patch has landed in central?
Anything else needed could be tracked under a separate bug. It adds complexity to tracking otherwise.
No problem - done.
Assignee | ||
Updated•6 months ago
|
Updated•6 months ago
|
Assignee | ||
Comment 22•6 months ago
|
||
Reporter | ||
Comment 23•6 months ago
|
||
Comment 24•6 months ago
|
||
Comment on attachment 9398859 [details]
Bug 1890607 - Publish Windows aarch64 msix to archive.mozilla.org
Approved for 126.0b7
Comment 25•6 months ago
|
||
uplift |
Updated•6 months ago
|
Assignee | ||
Comment 26•6 months ago
|
||
Description
•