Automate winget package submission#20029
Conversation
There was a problem hiding this comment.
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-wingetjob that runs after thereleasejob onrelease-*tags. - Fetches the published installer URL from the GitHub release and runs
wingetcreate update ... --submitusing a repository secret token.
LeonarddeR
left a comment
There was a problem hiding this comment.
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.WingetcreateThat 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.
|
Thanks for this PR - can you make sure to update the CI readme too? |
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
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. |
|
@seanbudd The README should be updated. Let me know if I missed anything in it though |
This is helpful! Even better micht be using
I think it can be left up to the bot if the following happens:
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 |
@LeonarddeR
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 The other 1,2,3, steps that you mentioned seem right to me |
XLTechie
left a comment
There was a problem hiding this comment.
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.
Move script to a separate .ps1 file & use WinGet to install wingetcreate
|
@seanbudd Moving this to "Ready for review" since I was able to get back to your feedback. Feel free to move it back to draft if you marked it for another reason |
Co-authored-by: Leonard de Ruijter <3049216+LeonarddeR@users.noreply.github.com>
Qchristensen
left a comment
There was a problem hiding this comment.
All reads well. Since this section is on Downloading NVDA, I added a link to the main download page (If people read this section and aren't sure, they should go there. If they read it and know what WinGet is and want to use that, the details are there for them).
Co-authored-by: Quentin Christensen <quentin@nvaccess.org>
|
Thanks @mdanish-kh @LeonarddeR - I think 2026.3 will be the first beta series for us to publish - is there anything we need to do to handle switch over? |
|
I think I will have to disable my automatic workflow re the NVDA packages when beta versions start to land. That said, the pull request for a new beta will be filed against winget earlier than my flow kicks in, and my flow checks for open pull requests, so it won't create a duplicate. |
Link to issue number:
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_TOKENthat's a public access token (classic) withpublic_reposcope 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:
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--submitflag to avoid sending an actual PR.Known issues with pull request:
The
WINGET_CREATE_GITHUB_TOKENneeds 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.