Automate winget package submission

[mdanish-kh]

Link to issue number:

• Resolves Official and documented winget publishing #18824
• https://x.com/NVAccess/status/2046802073312960733

Summary of the issue:

PR adds a post-release step to the current CI to submit the updated manifest to WinGet Community Repository. microsoft/winget-create is the tool used for creating and submitting the manifest through a PR

If the maintainers approve of this change, we need to then 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 for submitting a PR. Recommend using a bot account for this purpose.

Description of user facing changes:

WinGet users may see less delay in NVDA packages being published at the WinGet repository. Follows from the conversation in https://x.com/NVAccess/status/2046802073312960733

Description of developer facing changes:

N/A

Description of development approach:

Use a GitHub Action workflow similar to how implemented in the following repos:

• HTTPToolkit
• Microsoft PowerToys
• Microsoft Terminal
• Microsoft Copilot CLI
• Microsoft Edit
• WinGet Studio
• Oh-My-Posh

Testing strategy:

Tested the commands locally on my machine using placeholder values for ${{ github.ref_name }} & ${{ github.repository }}. For testing with wingetcreate just omit the --submit flag to avoid sending an actual PR.

wingetcreate.exe update NVAccess.NVDA `
--version 2025.3.3 `
--urls https://github.com/nvaccess/nvda/releases/download/release-2025.3.3/nvda_2025.3.3.exe

Known issues with pull request:

The WINGET_CREATE_GITHUB_TOKEN needs to be kept updated and unfortunately one can not use a fine-grained token at the moment (blocked by lacking GitHub API support)

Code Review Checklist:

Most of this is unrelated to my change as it's only a GitHub action workflow, not a change in the product itself. Let me know though if I need to update any documentation.

- [ ] Documentation:
- Change log entry
- User Documentation
- Developer / Technical Documentation
- Context sensitive help for GUI changes
- [ ] Testing:
- Unit tests
- System (end to end) tests
- Manual testing
- [ ] UX of all users considered:
- Speech
- Braille
- Low Vision
- Different web browsers
- Localization in other languages / culture than English
- [ ] API is compatible with existing add-ons.
- [ ] Security precautions taken.

[Copilot]

Pull request overview

Adds an automated post-release CI step to submit/update NVDA’s manifest in the WinGet Community Repository using wingetcreate, reducing lag between GitHub releases and WinGet availability.

Changes:

• Introduces a new submit-winget job that runs after the release job on release-* tags.
• Fetches the published installer URL from the GitHub release and runs wingetcreate update ... --submit using a repository secret token.

[Copilot]

This step downloads and executes wingetcreate.exe directly from the network without pinning a specific version or performing any integrity verification. To reduce supply-chain risk and improve reproducibility, consider pinning to a known release version and verifying its checksum/signature (or using a trusted distribution mechanism) before executing it.

[mdanish-kh]

(or using a trusted distribution mechanism)

aka.ms is a trusted Microsoft domain.

If it's not a maintenance burden, one can pin to a specific wingetcreate release. The latest release will always generate the manifest with the latest (& non-deprecated) WinGet schema version.

[denelon]

The wingetcreate releases at GitHub do include a SHA256, but pinning to a specific version puts the burden on maintainers to update to a newer version when it's released. Otherwise, there is a risk of an "older" schema version being used to submit the PR which will eventually be deprecated for use at the WinGet Community Repository.

[LeonarddeR]

As the current maintainer of the NVDA WinGet submission, I"m happy to get this upstreamed. Note that the current submission flow is stored here.
I'm using the current approach to install winget-create

      - name: Install Winget PowerShell
        run:           Install-PSResource Microsoft.WinGet.Client   -TrustRepository
      - name: Install wingetcreate
        run: Install-WinGetPackage -Id Microsoft.Wingetcreate

That said, that's because I"m performing some extra validation before submitting.

Also note that my flow runs once every two hours, so the current pull request against the winget repo is no later than two hours after the new release is advertised using the update check mechanism.

And as a last point of consideration, I think that it makes sense that there's a human that can control the winget pull request, especially when the winget maintainers are asking author feedback.

[seanbudd]

Thanks for this PR - can you make sure to update the CI readme too?

[mdanish-kh]

I'm using the current approach to install winget-create

I see, generally you don't need the PowerShell module in a CI environment to install wingetcreate since the team has made it directly available via these short URLs

• https://aka.ms/wingetcreate/latest
• https://aka.ms/wingetcreate/latest/msixbundle

I think that it makes sense that there's a human that can control the winget pull request

I agree, ideally someone should be able to control the bot account if we're automating it and make changes if necessary. Although if we agree on the base manifest already on winget-pkgs, then the changes should only be minimal for the new version (new InstallerUrl, new hash) and rest of the metadata should remain same. The goal is to have minimal feedback loop and get the PR merged as soon as possible, and being done through an official mechanism can help WinGet maintainers speed up the loop.

[mdanish-kh]

@seanbudd The README should be updated. Let me know if I missed anything in it though

[LeonarddeR]

I see, generally you don't need the PowerShell module in a CI environment to install wingetcreate since the team has made it directly available via these short URLs

This is helpful! Even better micht be using choco install -y wingetcreate. Not that I don't trust Microsoft's URLs, but it makes sense to use an uniform pattern to install dependencies. We're also using it for other tools in the workflow.

I agree, ideally someone should be able to control the bot account if we're automating it and make changes if necessary.

I think it can be left up to the bot if the following happens:

1. @nvaccessAuto creates the pr (the token used by winget-create should be from that user)
2. NV Access organisation members get full access on the winget-pkgs fork on @nvaccessAuto
3. If members want to close the pr, they can just remove the branches from the fork. Github will close the pr automatically.

Ideally, winget-create allowed us to choose our own fork. In that case, I believe that a fork owner can also control the pr through Github's interface. See microsoft/winget-create#470

[seanbudd]

Please also document the setup required for this to happen further down. We try to document all steps needed to get the CI working.

[mdanish-kh]

@seanbudd done, please check. I'm happy to follow up if I missed anything

[mdanish-kh]

Even better micht be using choco install -y wingetcreate

@LeonarddeR aka.ms/wingetcreate/latest is updated as part of release process of winget-create so it's always pointing to the latest. If choco update process is swift and would always point to the latest version, then it should be fine

Ideally, winget-create allowed us to choose our own fork. In that case, I believe that a fork owner can also control the pr through Github's interface.

I didn't quite get that, could you please explain a bit more? Usually, the fork is created under the user account whose token is used. For submitting to a different repo, you can configure the WindowsPackageManagerRepository setting using wingetcreate settings command. winget-create doesn't have support yet for a --repo param so the settings file need to be updated first if we're doing it in a CI environment.

The other 1,2,3, steps that you mentioned seem right to me

[XLTechie]

Approving the CI readme change.

Shouldn't this have a changes.md entry? The fact that this is becoming part of the official build process should be advertised to those who might care, and promoting that Winget includes NVDA latest is good marketing.