Reusable workflow for publishing package to WinGet

[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 (@pwshBot ?) for this purpose.

PR Context

Re-usable workflow version of PR:

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

[mdanish-kh]

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

[anamnavi]

Had a question, but non-blocking and LGTM

[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

[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.ps1 script 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?

[mdanish-kh]

@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

[anamnavi]

that makes sense for scope, thanks for clarifying!

@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

[mdanish-kh]

@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.PowerShell
PackageVersion: 7.5.4.0
Installers:
- Architecture: x64
  InstallerType: wix
  InstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-x64.msi
  InstallerSha256: 84A39D39F113F884333686C4DF70BC6C517F5B5D3982D88B4A0139F10EBB3FCB
  ProductCode: '{E8159677-ACF8-4D64-9D36-5C36B8BBEA39}'
- Architecture: x86
  InstallerType: wix
  InstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-x86.msi
  InstallerSha256: 397126D6C186ECF0A5F6F572D920E87F8602B728BE5B299B3401F34FB168B507
  ProductCode: '{C0EB62EC-3584-4297-9585-00376F6598E6}'
- Architecture: arm64
  InstallerType: wix
  InstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-arm64.msi
  InstallerSha256: B7757B4D2477CE3A4426D87B1B84D827B2272F83C75C1C0C9FBC21264DA3ADCE
  ProductCode: '{65823C8A-B1A9-40BD-AB10-D8174890930C}'
- Architecture: arm
  InstallerType: wix
  InstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4-win-arm64.msi
  InstallerSha256: B7757B4D2477CE3A4426D87B1B84D827B2272F83C75C1C0C9FBC21264DA3ADCE
  ProductCode: '{65823C8A-B1A9-40BD-AB10-D8174890930C}'
- Platform:
  - Windows.Universal
  MinimumOSVersion: 10.0.17763.0
  Architecture: arm64
  InstallerType: msix
  InstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4.msixbundle
  InstallerSha256: B8EB615A572056659AE8F74F45DF8EF4B1C78524FC0F21A752D02A132EBD8C03
  SignatureSha256: 052B1C58B50874A055F288B86C8307FD45A5560A6BAE5B4D5C69810126F2C7B4
  PackageFamilyName: Microsoft.PowerShell_8wekyb3d8bbwe
- Platform:
  - Windows.Universal
  MinimumOSVersion: 10.0.17763.0
  Architecture: x64
  InstallerType: msix
  InstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4.msixbundle
  InstallerSha256: B8EB615A572056659AE8F74F45DF8EF4B1C78524FC0F21A752D02A132EBD8C03
  SignatureSha256: 052B1C58B50874A055F288B86C8307FD45A5560A6BAE5B4D5C69810126F2C7B4
  PackageFamilyName: Microsoft.PowerShell_8wekyb3d8bbwe
- Platform:
  - Windows.Universal
  MinimumOSVersion: 10.0.17763.0
  Architecture: x86
  InstallerType: msix
  InstallerUrl: https://github.com/PowerShell/PowerShell/releases/download/v7.5.4/PowerShell-7.5.4.msixbundle
  InstallerSha256: B8EB615A572056659AE8F74F45DF8EF4B1C78524FC0F21A752D02A132EBD8C03
  SignatureSha256: 052B1C58B50874A055F288B86C8307FD45A5560A6BAE5B4D5C69810126F2C7B4
  PackageFamilyName: Microsoft.PowerShell_8wekyb3d8bbwe
ManifestType: installer
ManifestVersion: 1.10.0
ReleaseDate: 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.

[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?

[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.