Repository navigation
Request: Automatically publish new releases of the formatter to Windows Package Manager (winget) #239
Description
Activity
Thanks for the suggestion.
@NathanLovato would it be okay if I try setting up a GitHub Actions workflow to automate Winget publishing for
gdscript-formatter, so new releases can be updated in the Windows Package Manager automatically?I’m not very familiar with Winget automation yet, so I’d take it step by step while experimenting with it.
here is ci setup
winget: name: Publish to Winget Package Manager runs-on: windows-latest needs: release permissions: contents: read pull-requests: write env: WINGET_CREATE_GITHUB_TOKEN: ${{ secrets.WINGET_PAT }} # for pull request steps: - name: Setup WingetCreate shell: pwsh run: curl.exe -L https://aka.ms/wingetcreate/latest -o wingetcreate.exe - name: Publish to Winget shell: pwsh run: | $version = "${{ github.ref_name }}" $urls = @( "https://github.com/GDQuest/GDScript-formatter/releases/download/$version/gdscript-formatter-$version-windows-x86_64.exe.zip|x64", "https://github.com/GDQuest/GDScript-formatter/releases/download/$version/gdscript-formatter-$version-windows-aarch64.exe.zip|arm64" ) .\wingetcreate.exe update gdscript-formatter --version $version --urls $urls --submit
Absolutely, yes, your help is most welcome and much appreciated @DevTwilight! These features are beyond the scope of what I can work on myself at the moment and I'm sure people who use the windows package manager will appreciate automatic updates.
For reference, I checked this page from the Microsoft documentation to get some info about how to first publish as well. https://learn.microsoft.com/en-us/windows/powertoys/command-palette/publish-extension-winget
Keeping this around for reference to do the initial publication of the package.
Thanks for the confirmation.
From my understanding, setting up Winget publishing requires two steps to get started:
-
Initial manual publication (first Winget package submission using WingetCreate):
https://github.com/microsoft/winget-create/blob/main/doc/new.md -
GitHub Personal Access Token (classic) setup for CI automation:
https://github.com/microsoft/winget-create/blob/main/doc/token.md
Would you be able to handle the initial Winget setup (first package submission) and generate the required PAT (with
public_reposcope) for CI? Once that’s done, I can set up the GitHub Actions workflow for automated updates.-
sorry but any updates
Sorry I forgot to get back to you, but yes, absolutely, I can handle the initial setup. I might just take a while to get to it because of my current workload + limited free time (projects like these I maintain in my free time).
no problem just make sure to get back after initial publish when u have time
Dropping by just to say I'm not forgetting this. I decided to prioritize rewriting the formatter after talking with a contributor and with Godot engine maintainers; I got rid of some dependencies and wanted to really consolidate it and making it a better program for users before publishing the packages (the formatter, while functional, was still a relatively low quality program with its bunch of regex hacks stacked around Topiary)
@NathanLovato, just a small update on this issue.
The package has now been published to the Windows Package Manager by @Dragon1573:
Since the package is now available via Winget, I think this request has effectively been completed, so it probably makes sense to close this issue. If CI automation for future Winget manifest updates is still desired, that can always be tracked in a separate issue or PR.
Thank you @DevTwilight for the heads up, @rafasoares for bringing it up to the winget tracker and @Dragon1513 for the PR!
Sorry, but this issue was mostly about automating the publishing, so I'm not sure if I'd consider it complete (unless you're closing it as "not planned", which is understandable).
The winget version is already outdated, which might be detrimental to the UX.
@DevTwilight I didn't look too closely at the setup, but couldn't you use the currently published manifest as a base to set up the CI action?
I might also take a stab at it, if you're unavailable.
Since the initial publication is complete, this issue can be considered resolved.
For future releases, we could add a GitHub Actions workflow to automate WinGet updates. A possible workflow:
winget: name: Publish to WinGet runs-on: windows-latest needs: release permissions: contents: read pull-requests: write env: WINGET_CREATE_GITHUB_TOKEN: ${{ secrets.WINGET_PAT }} steps: - name: Setup WingetCreate shell: pwsh run: curl.exe -L https://aka.ms/wingetcreate/latest -o wingetcreate.exe - name: Publish to WinGet shell: pwsh run: | $version = "${{ github.ref_name }}" $urls = @( "https://github.com/GDQuest/GDScript-formatter/releases/download/$version/gdscript-formatter-$version-windows-x86_64.exe.zip|x64", "https://github.com/GDQuest/GDScript-formatter/releases/download/$version/gdscript-formatter-$version-windows-aarch64.exe.zip|arm64" ) .\wingetcreate.exe update GDQuest.GDScript.Formatter --version $version --urls $urls --submit
This would automatically create WinGet update PRs whenever a new release is published.
we only need GitHub Personal Access Token (classic) setup for CI automation:
- changed the title
[-]Request: Please consider publishing to Windows Package Manager (`winget`)[/-][+]Request: Automatically publish new releases of the formatter to Windows Package Manager (`winget`)[/+]on Jul 29, 2026 i want to work on this just let me know if is okay
Reacted by Rafael SoaresAbsolutely yes help is most welcome on every open issue, in particular ones like this that need time to learn and test a new tool/environment, even if it's not a huge time commitment; being maintainer of many repositories it all adds up.
- added a commit that references this issue
on Sep 14, 2026 We have now automated WinGet publishing in CI using
wingetcreate update --submit.The remaining issue is our versioned Windows executable layout:
gdscript-formatter-0.26.0-windows-x86_64.exe.zip └── gdscript-formatter-0.26.0-windows-x86_64.exeBecause the executable filename changes with every release,
NestedInstallerFiles.RelativeFilePathalso needs to change: which is not possible right now i guess@NathanLovato what to do now any idea
If it's problematic, I'd say let's just remove the version numbers in the artifact files, and then people can run the version flag from the program to get the version or read the version from the release tag.
Actually, for the Godot add on for publishing new versions to the GDQuest website or the asset library, there's the same thing where I cannot give it a regular expression or pattern to read from. It has to be an exact URL that does not change.
For the GDQuest website, I could code something to automatically read a local copy of the formatter repository for last release info but I'd rather not do that if possible for now (because of my available time).
It will just take changes in a couple places. There is the CI, there is also the add on download and install logic, and I will need to also go update a few links here and there across the web.
don't worry i will look into and investigate for a solution because removing the version can break #168
just give me some time
I think we should close this as out of scope for now.
wingetcreate update --submitcannot currently handle our versioned nested executable automatically becauseNestedInstallerFiles.RelativeFilePathchanges with every release.Interactive mode can resolve the new path, but it requires an interactive console and therefore isn't suitable for CI. The alternative would be to maintain our own manifest generation/submission flow instead of relying on
wingetcreate update --submit, which feels like unnecessary complexity for this project.We also shouldn't remove the version from the executable filename just to support WinGet. This naming is already relied upon by existing distributions. In particular, changing it could break the AUR packaging that was fixed in #168, as well as the current Godot add-on and potentially the VS Code extension.
Changing the artifact layout would therefore risk breaking existing distribution channels in order to support a new one. That doesn't seem feasible or appropriate.
We can revisit this if
wingetcreategains support for updating versioned nested installer paths non-interactively.Thanks for looking into this. How about duplicating the Windows build artifact and naming it something stable like
winget_build_gdscript_formatter_x64and whatever other variant needed? So that it does not risk breaking any other distribution.Thanks for the suggestion! However, I'd prefer to avoid maintaining a duplicate build artifact just to support
winget, as it adds unnecessary maintenance overhead.
Fortunately, @damn-good-b0t automatically handles the updates for us whenever a new release goes live—you can look at its latest pull request here: microsoft/winget-pkgs#434463. On top of that, if the package ever happens to lag behind, users can simply open an issue to flag it.Additionally, I propose that we update PR #313 to remove the
wingetjob that handles publishing, since we don't need to manage it anymore.Okay, sounds good, let's do that then, If the update automation is already handled by a bot that works
Reacted by Rafael Soares
I have opened a request to publish the latest version of
gdscript-formattertowinget, but it would be nice if the manifest generation and publishing could be automated, so new versions are more readily available.There are CLI tools available, so it should be relatively easy to do it using CI, like Github Actions.
More documentation can be found at https://learn.microsoft.com/en-us/windows/package-manager/package/
Thank you.