Skip to content

Add winget manifest generator and release automation - #57

Merged
JeremySNR merged 2 commits into
mainfrom
cursor/winget-manifest-627e
Sep 6, 2026
Merged

Add winget manifest generator and release automation#57
JeremySNR merged 2 commits into
mainfrom
cursor/winget-manifest-627e

Conversation

@JeremySNR

Copy link
Copy Markdown
Owner

What does this change?

Addresses #47. Adds:

  • scripts/print-winget-manifest.mjs — generates the three winget-pkgs YAML files from a GitHub release (tested against v0.7.0’s ClipForge-Setup-0.7.0.exe)
  • a Release workflow job that runs winget-releaser after the first listing exists
  • docs/winget.md for the one-off first submit to microsoft/winget-pkgs

This cannot complete the first microsoft/winget-pkgs PR from here (that needs a PAT that can fork that repo). Once that listing is accepted, set WINGET_PACKAGE_ID=JeremySNR.ClipForge and WINGET_TOKEN, and later releases stay in sync.

Why?

Most downloads are the Windows installer. winget install JeremySNR.ClipForge is how those users expect to install.

How did you test it?

  • npm test (including tests/wingetManifest.test.ts)
  • npm run typecheck
  • npm run lint
  • node scripts/print-winget-manifest.mjs 0.7.0 --out … against the live v0.7.0 release

Anything to watch out for?

The winget job is a no-op until WINGET_PACKAGE_ID is set, so ordinary releases do not fail. The app is still unsigned; winget allows that, SmartScreen will still prompt.

Open in Web Open in Cursor 

Windows is most of the downloads. Generate a winget-pkgs YAML trio from
the GitHub release, document the first submit, and optionally update the
package on later releases once WINGET_PACKAGE_ID and WINGET_TOKEN are set.

Addresses #47

Co-authored-by: Jeremy Smith <JeremySNR@users.noreply.github.com>
@JeremySNR
JeremySNR marked this pull request as ready for review September 6, 2026 11:33
@JeremySNR
JeremySNR merged commit 43a9952 into main Sep 6, 2026
4 checks passed

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

Bugbot Autofix prepared a fix for the issue found in the latest run.

  • ✅ Fixed: Winget job uses branch as tag
    • Added checkout and a package.json version step so winget-releaser receives release-tag v$version instead of falling back to github.ref_name (main) on non-tag runs.

You can send follow-ups to the cloud agent here.

Reviewed by Cursor Bugbot for commit 3344f06. Configure here.

with:
identifier: ${{ vars.WINGET_PACKAGE_ID }}
installers-regex: '\.exe$'
token: ${{ secrets.WINGET_TOKEN }}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Winget job uses branch as tag

Medium Severity

The winget job never passes release-tag, so winget-releaser falls back to github.ref_name. Tag pushes resolve correctly, but a Release v commit or workflow_dispatch from main looks up a release named main and publishing fails. The notes job already reads the version from package.json for this same workflow.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 3344f06. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants