ci(build): produce PDFApps-<version>.msix on every release#46
Merged
Conversation
Add an MSIX build step to the Windows job in build.yml so the Microsoft Store / sideload package is built automatically alongside PDFAppsSetup.exe / PDFApps.exe instead of needing a separate manual pwsh msix/build.ps1 invocation. - The new step runs after PyInstaller produces dist/PDFApps.exe and invokes msix/build.ps1. windows-latest images already include the Windows 10/11 SDK so makeappx.exe is on PATH for the script. - The Publisher CN is read from the optional secret MSIX_PUBLISHER_CN. When set (post-name-reservation in Microsoft Partner Center), the MSIX carries the production CN and is ready for Store upload. When unset (initial scaffolding period, public forks), build.ps1 falls back to its sideload-test CN — the resulting .msix isn't Store-submittable but lets contributors validate the manifest locally. - The .msix is uploaded as part of the PDFApps-Windows artifact and attached to the GitHub Release alongside PDFAppsSetup.exe etc., with a SHA256 line so the in-app updater's hash-verification path treats it like any other release asset. Workflow stays a no-op for the project until the user reserves the package name in Partner Center and adds MSIX_PUBLISHER_CN as a repo secret. Until then every release just gets a sideload-test .msix that confirms the build pipeline works end-to-end. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Wires the MSIX build (added in PR #45) into build.yml so a
PDFApps-<version>.msixis produced automatically on every release tag, alongsidePDFAppsSetup.exe,PDFApps.exe, etc.Changes
Build MSIX (Windows)runs after PyInstaller producesdist/PDFApps.exeand invokespwsh msix/build.ps1.windows-latestrunners already include the Windows 10/11 SDK somakeappx.exeis on PATH.MSIX_PUBLISHER_CN. When set (post-name-reservation in Microsoft Partner Center), the MSIX carries the production CN and is Store-ready. When unset (initial scaffolding period, public forks),build.ps1falls back to its sideload-test CN — the resulting.msixisn't Store-submittable but lets the build pipeline validate end-to-end..msixis included in thePDFApps-Windowsartifact and attached to the GitHub Release with a SHA256 checksum line, matching the existing release asset pattern.Test plan
dist/PDFApps-<version>.msixand that it lands as a release asset.MSIX_PUBLISHER_CNis set: re-run the build, confirm the MSIX manifest'sPublishermatches.Note
The IDE flags
secrets.MSIX_PUBLISHER_CNas "context access might be invalid" because the secret isn't defined yet in repo settings. That's a static lint false positive — at runtime an undefined secret resolves to empty, whichbuild.ps1treats as the sideload-test fallback.🤖 Generated with Claude Code