Build the submit action #1

New issue

Closed

opened 2026-10-14 01:02:04 -05:00 by jeff · 0 comments

jeff commented

2026-10-14 01:02:04 -05:00

Owner

Part of jeff/winget-pkgs#4
Blocked by: jeff/winget-pkgs#7

Build the action itself: a composite Forgejo action that makes a submission to jeff/winget-pkgs for a new release of a program, pinned by commit from each program the way niks3-push is. It handles only git and Forgejo; the manifest is written by wingetsource new-version from a checkout of jeff/winget-pkgs at main (ADR 0004 there, jeff/winget-pkgs#6).

Shape

Like niks3-push: action.yml with runs: using: composite, one step running nix run "path:${{ github.action_path }}#submit", the script and its tools coming from this repository's flake. The script is Python.

Inputs

Input	Required	Meaning
`identifier`	yes	Package identifier, e.g. `JCOllie.Clipwatch`
`version`	yes	The version to submit
`installers`	yes	One `<architecture> <url>` per line
`release-notes-url`	no	Passed to `--release-notes-url`
`release-date`	no	Passed to `--release-date`; `new-version` defaults it to today in UTC
`token`	yes	The submitter's token, `secrets.WINGET_BOT_TOKEN`
`dry-run`	no	Do everything but push and open the pull request; print the diff

The forge (https://git.jcollie.dev) and the repository (jeff/winget-pkgs) are built in, not inputs. The action does not judge whether a version is a prerelease; the calling workflow decides whether to call it.

Steps

Clone jeff/winget-pkgs at main with the token.
Run nix develop -c python3 -m wingetsource new-version ... there, passing the inputs through. Its failure (existing version directory, no previous version, different architectures) is the action's failure.
Run nix develop -c python3 -m wingetsource check --manifests manifests --changed-since origin/main there. On failure, print its problems and stop without pushing.
Commit as winget-bot with the message JCOllie.<Program> <version>, on the branch submit/JCOllie.<Program>/<version>.
Force-push the branch. If an open pull request from it already exists (a re-run release job), leave it as it is; otherwise open one titled JCOllie.<Program> <version>, whose body links the program's release, the workflow run that opened it, and the version it copied from.

Also

README: what the action does, its inputs, and an example step for a program's release.yml, including WINGET_BOT_TOKEN and skipping prereleases. Replace the note that says there is no action yet.
A Forgejo workflow for this repository from the usual template.
Tests for the parts that are not git or HTTP: parsing installers, the branch name and title, and the pull request body.

Done when

A dry-run against the real jeff/winget-pkgs with a Clipwatch version prints the expected new directory and a passing check, and CI is green.

Part of jeff/winget-pkgs#4 Blocked by: jeff/winget-pkgs#7 Build the action itself: a composite Forgejo action that makes a **submission** to `jeff/winget-pkgs` for a new release of a program, pinned by commit from each program the way `niks3-push` is. It handles only git and Forgejo; the manifest is written by `wingetsource new-version` from a checkout of `jeff/winget-pkgs` at `main` (ADR 0004 there, jeff/winget-pkgs#6). ## Shape Like `niks3-push`: `action.yml` with `runs: using: composite`, one step running `nix run "path:${{ github.action_path }}#submit"`, the script and its tools coming from this repository's flake. The script is Python. ## Inputs | Input | Required | Meaning | | --- | --- | --- | | `identifier` | yes | Package identifier, e.g. `JCOllie.Clipwatch` | | `version` | yes | The version to submit | | `installers` | yes | One `<architecture> <url>` per line | | `release-notes-url` | no | Passed to `--release-notes-url` | | `release-date` | no | Passed to `--release-date`; `new-version` defaults it to today in UTC | | `token` | yes | The submitter's token, `secrets.WINGET_BOT_TOKEN` | | `dry-run` | no | Do everything but push and open the pull request; print the diff | The forge (`https://git.jcollie.dev`) and the repository (`jeff/winget-pkgs`) are built in, not inputs. The action does not judge whether a version is a prerelease; the calling workflow decides whether to call it. ## Steps 1. Clone `jeff/winget-pkgs` at `main` with the token. 2. Run `nix develop -c python3 -m wingetsource new-version ...` there, passing the inputs through. Its failure (existing version directory, no previous version, different architectures) is the action's failure. 3. Run `nix develop -c python3 -m wingetsource check --manifests manifests --changed-since origin/main` there. On failure, print its problems and stop without pushing. 4. Commit as `winget-bot` with the message `JCOllie.<Program> <version>`, on the branch `submit/JCOllie.<Program>/<version>`. 5. Force-push the branch. If an open pull request from it already exists (a re-run release job), leave it as it is; otherwise open one titled `JCOllie.<Program> <version>`, whose body links the program's release, the workflow run that opened it, and the version it copied from. ## Also - README: what the action does, its inputs, and an example step for a program's `release.yml`, including `WINGET_BOT_TOKEN` and skipping prereleases. Replace the note that says there is no action yet. - A Forgejo workflow for this repository from the usual template. - Tests for the parts that are not git or HTTP: parsing `installers`, the branch name and title, and the pull request body. ## Done when A `dry-run` against the real `jeff/winget-pkgs` with a Clipwatch version prints the expected new directory and a passing check, and CI is green.

jeff added the

ready-for-agent

label

2026-10-14 01:02:04 -05:00

jeff referenced this issue from jeff/clipwatch

2026-10-14 01:02:15 -05:00

Submit new versions to the JCOllie winget source #1

jeff added a new dependency

2026-10-14 01:02:20 -05:00

jeff/winget-pkgs#7 - Add wingetsource new-version

jeff added a new dependency

2026-10-14 01:02:20 -05:00