Skip to content

Conversation

@mokagio
Copy link
Contributor

@mokagio mokagio commented Nov 4, 2024

Related to pesfPa-19a-p2

Proposed Changes

  • Add automation to generate two AppX packages, one signed for local testing and one unsigned for upload to the Windows Store
  • Call automation in the Windows Dev|Release build CI step (the Release branch was tested bypassing the tag check in Test PR for AppX build #613)
  • Store packages as CI artifacts

image

Testing Instructions

  • Download the signed version and run in on a Windows machine or VM.

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors? – N.A.

@mokagio mokagio force-pushed the mokagio/build-appx branch from 3efa7d1 to 9f5c2c6 Compare November 4, 2024 02:52
@mokagio mokagio force-pushed the mokagio/build-appx branch from 9f5c2c6 to 738075d Compare November 4, 2024 03:02
@@ -0,0 +1 @@
20348 No newline at end of file
Copy link
Contributor Author

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 }...` );
Copy link
Contributor Author

@mokagio mokagio Nov 4, 2024

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:

image

The flow with the signed version still results in multiple warnings, but clicking through them one can eventually run the app:

image

image

image

image

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.

Copy link
Member

@sejas sejas Nov 12, 2024

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!

Copy link
Contributor

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?

Copy link
Member

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:

studio/src/renderer.ts

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,
} );

@mokagio mokagio force-pushed the mokagio/build-appx branch from c6751ad to 76501a2 Compare November 4, 2024 03:40
@mokagio mokagio marked this pull request as ready for review November 4, 2024 04:01
@mokagio mokagio requested review from sejas and wojtekn November 4, 2024 04:06
...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
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Microsoft Store code signs on upload. This setup is successful

image

Kindly provided by @matt-west

See pesfPa-1cz-p2#comment-763
Copy link
Member

@sejas sejas left a 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 }

Copy link
Member

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?

Copy link
Contributor Author

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",
Copy link
Member

@sejas sejas Nov 12, 2024

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.

Copy link
Contributor Author

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.

@mokagio mokagio merged commit fca15ed into trunk Nov 13, 2024
13 checks passed
@mokagio mokagio deleted the mokagio/build-appx branch November 13, 2024 03:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants