Reusable workflow for publishing package to WinGet

[Muhammad Danish (mdanish-kh)]

PR Summary

PR creates a GitHub action workflow to trigger on every stable release to publish Microsoft.PowerShell package to WinGet repository. microsoft/winget-create is the tool used for creating and submitting the manifest

Steps needed from maintainers

• Add a repository secret named WINGET_CREATE_GITHUB_TOKEN that's a public access token (classic) with public_repo scope from the user account where the winget-pkgs fork will exist. Recommend using a bot account (PowerShell Team Bot (@pwshBot) ?) for this purpose.

PR Context

Re-usable workflow version of PR:

• Add GitHub action for publishing releases to WinGet PowerShell#26310

[Muhammad Danish (mdanish-kh)]

Since this doesn't trigger off the release event, I used the GitHub API to query the latest stable release

[Anam Navied (anamnavi)]

Had a question, but non-blocking and LGTM

[Anam Navied (anamnavi)]

I've created this issue #57 to track updating the manifest for preview, I have the logic from our existing workflow and will update this code with it once this PR gets in

[Anam Navied (anamnavi)]

Also, the first time the msixbundle is to be added (i.e the manifest does not yet contain an entry for msix which it can update), the team can run the .YamlCreate.ps1script to create it. To confirm the entry would look like this, correct? (I've provided an old manifest entry with msixbundle). Or could you please link another team's existing manifest that has an msix entry for reference?

- Platform:
- Windows.Universal
Architecture: arm64
InstallerType: msix
Scope: user
InstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.4.1/PowerShell-7.4.1-win.msixbundle
InstallerSha256: E4C91DC9AB35C996ACB9B015A2577C4C0BE51CF30AB8DF4682B1DACC6A84748E
SignatureSha256: 50908775815BEC7418B248771A20F6D0FA1A2DBC174E3D87B38A4EF39DA5E2E8
PackageFamilyName: Microsoft.PowerShell_8wekyb3d8bbwe

What would the architecture be? Would scope be user? It is machine scope for our msi entries.

and then in our existing winget manifest, where InstallerType: wix is specified at the top it would get moved to the individual (msi) entries by wingetcreate.exe update, correct?

[Muhammad Danish (mdanish-kh)]

Anam Navied (@anamnavi) IIRC WinGet validation pipelines require that all of the MSIXBundle architectures are specified in the manifest, not a single one. So, in this case the installer node looks good but you would have to specify it for all architectures as well (the ones included in the MSIXBundle). Scope will be user for MSIXBundle, and you're correct to note that the root fields relevant for MSI installers, which are InstallerType: wix & Scope: machine, would be moved down to each MSI installer level

[Anam Navied (anamnavi)]

that makes sense for scope, thanks for clarifying!

Anam Navied (@anamnavi) IIRC WinGet validation pipelines require that all of the MSIXBundle architectures are specified in the manifest, not a single one. So, in this case the installer node looks good but you would have to specify it for all architectures as well (the ones included in the MSIXBundle).

do you mean that while we support both msi and msix installers, there would be 4 installer nodes for msixbundle (for x64, x86, arm, arm64) plus 4 installer nodes for msi's (for x64, x86, arm, arm64)? OR 4 installer nodes for msi (as it currently is) plus 1 for msixbundle

[Muhammad Danish (mdanish-kh)]

Anam Navied (@anamnavi) I ran the following command to see how the updated manifest should look like

wingetcreate new https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-x64.msi https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-x86.msi https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-arm64.msi https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-arm64.msi https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4.msixbundle

Output

PackageIdentifier: Microsoft.PowerShellPackageVersion: 7.5.4.0Installers:
- Architecture: x64InstallerType: wixInstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-x64.msiInstallerSha256: 84A39D39F113F884333686C4DF70BC6C517F5B5D3982D88B4A0139F10EBB3FCBProductCode: '{E8159677-ACF8-4D64-9D36-5C36B8BBEA39}'
- Architecture: x86InstallerType: wixInstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-x86.msiInstallerSha256: 397126D6C186ECF0A5F6F572D920E87F8602B728BE5B299B3401F34FB168B507ProductCode: '{C0EB62EC-3584-4297-9585-00376F6598E6}'
- Architecture: arm64InstallerType: wixInstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-arm64.msiInstallerSha256: B7757B4D2477CE3A4426D87B1B84D827B2272F83C75C1C0C9FBC21264DA3ADCEProductCode: '{65823C8A-B1A9-40BD-AB10-D8174890930C}'
- Architecture: armInstallerType: wixInstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-arm64.msiInstallerSha256: B7757B4D2477CE3A4426D87B1B84D827B2272F83C75C1C0C9FBC21264DA3ADCEProductCode: '{65823C8A-B1A9-40BD-AB10-D8174890930C}'
- Platform:
- Windows.UniversalMinimumOSVersion: 10.0.17763.0Architecture: arm64InstallerType: msixInstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4.msixbundleInstallerSha256: B8EB615A572056659AE8F74F45DF8EF4B1C78524FC0F21A752D02A132EBD8C03SignatureSha256: 052B1C58B50874A055F288B86C8307FD45A5560A6BAE5B4D5C69810126F2C7B4PackageFamilyName: Microsoft.PowerShell_8wekyb3d8bbwe
- Platform:
- Windows.UniversalMinimumOSVersion: 10.0.17763.0Architecture: x64InstallerType: msixInstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4.msixbundleInstallerSha256: B8EB615A572056659AE8F74F45DF8EF4B1C78524FC0F21A752D02A132EBD8C03SignatureSha256: 052B1C58B50874A055F288B86C8307FD45A5560A6BAE5B4D5C69810126F2C7B4PackageFamilyName: Microsoft.PowerShell_8wekyb3d8bbwe
- Platform:
- Windows.UniversalMinimumOSVersion: 10.0.17763.0Architecture: x86InstallerType: msixInstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4.msixbundleInstallerSha256: B8EB615A572056659AE8F74F45DF8EF4B1C78524FC0F21A752D02A132EBD8C03SignatureSha256: 052B1C58B50874A055F288B86C8307FD45A5560A6BAE5B4D5C69810126F2C7B4PackageFamilyName: Microsoft.PowerShell_8wekyb3d8bbweManifestType: installerManifestVersion: 1.10.0ReleaseDate: 2025-10-20

WinGetCreate didn't add Scope (only in this instance with the new command) so we can add Scope: machine for InstallerType: wix nodes and Scope: user for InstallerType: msix. Also, the MSIXBundle does not support arm (the 32-bit ARM), so the MSIX will be 3 installer nodes.

[Muhammad Danish (mdanish-kh)]

Also, I'm not sure why we have Architecture: arm in case of MSI as well since that really looks like a URL for arm64, but that was included in the previous manifest so WinGetCreate is copying it over. Maybe that URL works for arm32 as well?

[Anam Navied (anamnavi)]

Also, I'm not sure why we have Architecture: arm in case of MSI as well since that really looks like a URL for arm64, but that was included in the previous manifest so WinGetCreate is copying it over. Maybe that URL works for arm32 as well?

thanks for providing the command output and example, I'll use that command for the initial manifest creation when msix is added. And yes, PowerShell doesn't create a msi for arm32, so the intention was to provide the arm64 url which works for arm32 when arm is requested/detected.

[Muhammad Danish (mdanish-kh)]

Anam Navied (@anamnavi)Travis Plunk (@TravisEz13) Looping back if this can be looked at