Add template for publishing installers to winget for release #20563
Conversation
|
This PR has Quantification details
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a
What can I do to optimize my changes
How to interpret the change counts in git diff output
Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email) |
| echo $pkgId | ||
|
|
||
| # Update package using wingetcreate | ||
| Invoke-WebRequest https://aka.ms/wingetcreate/latest -OutFile wingetcreate.exe |
There was a problem hiding this comment.
This part should be in the image, but we can put this in the backlog
|
|
||
| # Update package using wingetcreate | ||
| Invoke-WebRequest https://aka.ms/wingetcreate/latest -OutFile wingetcreate.exe | ||
| .\wingetcreate.exe update $pkgId --version $version --urls $installerUrls --submit --token ${{ secrets.PR_PAT }} |
There was a problem hiding this comment.
This won't work if the previous manifest contains the MSIX installers. Winget-Create works when the number of new installer URLs match the number in the previous (base) manifest (the msixbundle link needs to be provided only once tho). My understanding is that the msixbundle is published sometime (1-2 days??) after the MSI releases; If this action triggers when the MSIs are published to GitHub and the previous winget manifest contains MSIX installer nodes as well, the current implementation of winget-create will fail to generate the PR.
The solution I can think of is one of these:
- Address this in winget-create's implementation to allow automated PRs with less number of installer nodes/URLs
- Release MSIXBundle at the same time as MSIs and update the action to generate the complete manifest with msixbundle included. Or wait till msixbundle URL is available on GitHub and run the action as soon as that happens (but that wouldn't be reasonable since the point of this automation is to get this package out ASAP)
- (I know you mentioned this but I'm unaware of its progress) Release MSIs for ARM architecture that are published at the same time as x64/x86. That way we wouldn't need to add msix in winget's manifest and the automation will work correctly
- Don't add MSIX for the "latest" winget manifest, add them for the previous version after the automated PR (that also doesn't sound reasonable to me. I'm just writing anything that can work 😄 )
- Try another manifest authoring tool? There are a couple community developed tools that can handle the task of automated PRs that may not be as strict as winget-create
|
This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 15 days. It will be closed if no further activity occurs within 10 days of this comment. |
PR Summary
When we do a PowerShell/PowerShell release use wingetcreate update to release info about the installers to winget.
PR Context
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:or[ WIP ]to the beginning of the title (theWIPbot will keep its status check atPendingwhile the prefix is present) and remove the prefix when the PR is ready.(which runs in a different PS Host).