-
Notifications
You must be signed in to change notification settings - Fork 53
Build AppX version in CI #643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
3efa7d1 to
9f5c2c6
Compare
9f5c2c6 to
738075d
Compare
| @@ -0,0 +1 @@ | |||
| 20348 No newline at end of file | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are later versions than this, but we know this works in CI. We can try newer versions later on.
| } ); | ||
|
|
||
| const appxOutputPathSigned = path.resolve( outPath, `${ appxName }-signed` ); | ||
| console.log( `~~~ Creating signed .appx for local testing at ${ appxOutputPathSigned }...` ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If one tries to launch the unsigned AppX, Windows refuses to enable the "Install" button:
The flow with the signed version still results in multiple warnings, but clicking through them one can eventually run the app:
I figured given the packaging process is relatively fast, it might be useful to generate both versions just in case we need to test something.
Alternatively, we can abstract this logic and generate the unsigned AppX only when building for release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there something we could do to avoid the extra warning alerts?
Alternatively, we can abstract this logic and generate the unsigned AppX only when building for release.
If it's not a big effort , limiting the AppX only for releases would be ideal. Thanks for the suggestion!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sejas this warning suppose to alert Mac users who run Intel binary on Apple Silicon chip, and I think it shouldn't pop up on Windows. Should we check it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created the issue to investigate it further:
https://github.com/Automattic/dotcom-forge/issues/9846
The message is indeed launched by Studio:
Lines 85 to 102 in 335c634
| // Show warning if running an ARM64 translator | |
| if ( appGlobals.arm64Translation && ! localStorage.getItem( 'dontShowARM64Warning' ) ) { | |
| const showARM64MessageBox = async () => { | |
| const { response, checkboxChecked } = await getIpcApi().showMessageBox( { | |
| type: 'warning', | |
| message: __( 'This version of Studio is not optimized for your computer' ), | |
| detail: | |
| window.appGlobals.platform === 'darwin' | |
| ? __( | |
| 'Downloading the Mac with Apple Silicon Chip version of Studio will provide better performance.' | |
| ) | |
| : __( | |
| 'Downloading the optimized version of Studio will provide better performance.' | |
| ), | |
| checkboxLabel: __( "Don't show this warning again" ), | |
| buttons: [ __( 'Download' ), __( 'Not now' ) ], | |
| cancelId: 1, | |
| } ); |
c6751ad to
76501a2
Compare
| ...sharedOptions, | ||
| // See details at https://partner.microsoft.com/en-us/dashboard/products/<id>/identity | ||
| publisher: 'CN=E2E5A157-746D-4B04-9116-ABE5CB928306', | ||
| devCert: 'nil', // skip code signing for Store upload |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kindly provided by @matt-west See pesfPa-1cz-p2#comment-763
sejas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fantastic! Thank you!
I left a comment about the electron2appx library, but it's not blocking this PR.
If it’s not too much effort, it would be ideal to limit the AppX generation to betas and final releases. As I don't think we need this format in the rest of PRs. This could be addressed in a follow-up.
| Get-ChildItem -Path $artifactsPath -Recurse -Include "*.nupkg" | Rename-Item -NewName "studio-update.nupkg" | ||
|
|
||
| If ($LastExitCode -ne 0) { Exit $LastExitCode } | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to remove this empty line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not make any difference functionally. But it was an unnecessary trailing new line.
| "cross-port-killer": "^1.4.0", | ||
| "date-fns": "^3.3.1", | ||
| "electron-squirrel-startup": "^1.0.0", | ||
| "electron2appx": "^2.1.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that PocketCasts also uses the electron2appx library. I’m surprised that the official guide https://www.electronjs.org/docs/latest/tutorial/windows-store-guide suggests one library and we actually need to use a fork of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is odd right? And what are the odds that no one run into the need for disabling code signing when building the appx? (I haven't actually investigated existing issues in the repo, maybe there are open ones in that regard. TODO)
We need this fork because we need to disable code signing. But it's possible the issue is with us having to disable code signing. That is, we should not have to do that.
The reason we have to do it is that the cert we use for code signing comes from a publisher, CN='Automattic, Inc.', O='Automattic, Inc.', S=California, C=US that is different from the one in the Store, CN=E2E5A157-746D-4B04-9116-ABE5CB928306. My team has an open task to add processes and tooling around the certificate management, so hopefully we'll discover more about this soon.






Related to pesfPa-19a-p2
Proposed Changes
Testing Instructions
Pre-merge Checklist