Request: Automatically publish new releases of the formatter to Windows Package Manager (winget)

I have opened a request to publish the latest version of gdscript-formatter to winget, 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.

@NathanLovato

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

@DevTwilight

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_repo scope) 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

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

@DevTwilight

Thank you @DevTwilight for the heads up, @rafasoares for bringing it up to the winget tracker and @Dragon1513 for the PR!

@DevTwilight

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:

i want to work on this just let me know if is okay

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

Fix/351 asset store duplicate (#352)

@NathanLovato

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

Because the executable filename changes with every release, NestedInstallerFiles.RelativeFilePath also 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 --submit cannot currently handle our versioned nested executable automatically because NestedInstallerFiles.RelativeFilePath changes 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 wingetcreate gains 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_x64 and whatever other variant needed? So that it does not risk breaking any other distribution.

@damn-good-b0t

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 winget job 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

Navigation Menu

Repository navigation

Request: Automatically publish new releases of the formatter to Windows Package Manager (`winget`) #239

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Request: Automatically publish new releases of the formatter to Windows Package Manager (winget) #239

Description

Activity

DevTwilight commented on Jun 5, 2026

DevTwilight commented on Jun 5, 2026

NathanLovato commented on Jun 5, 2026

DevTwilight commented on Jun 6, 2026

DevTwilight commented on Jun 15, 2026

NathanLovato commented on Jun 15, 2026

DevTwilight commented on Jun 15, 2026

NathanLovato commented on Jul 11, 2026

DevTwilight commented on Jul 29, 2026

NathanLovato commented on Jul 29, 2026

rafasoares commented on Jul 29, 2026

DevTwilight commented on Jul 29, 2026

DevTwilight commented on Jul 29, 2026

NathanLovato commented on Jul 29, 2026

DevTwilight commented on Sep 15, 2026

NathanLovato commented on Sep 16, 2026

DevTwilight commented on Sep 16, 2026

DevTwilight commented on Sep 18, 2026

NathanLovato commented on Sep 18, 2026

DevTwilight commented on Sep 19, 2026

NathanLovato commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Request: Automatically publish new releases of the formatter to Windows Package Manager (`winget`) #239