Submit new versions from harrier's release workflow #5

New issue

Closed

opened 2026-10-14 00:10:00 -05:00 by jeff · 1 comment

jeff commented

2026-10-14 00:10:00 -05:00

Owner

Once winget-submit exists (#4), each program's release workflow calls it
after a release is published, so that a new version reaches the source without
a hand-written pull request.

~~clipwatch~~: done. Its release.yml has a winget job (jeff/clipwatch#2),
and v0.2.1 was the first version submitted by itself (#13).
harrier: its release.yaml builds the MSI on a v<version> tag; submit
JCOllie.Harrier once it has a first, hand-written version (#3).

Only tagged, non-prerelease releases are submitted, with PackageVersion the
tag without its leading v. A rolling prerelease such as zettacom's never
is: it has no stable hash to pin. Each program repository needs the
winget-bot token as a secret, and pins winget-submit by commit.

What harrier still needs

Its first version, written by hand (#3).
wingetsource new-version to update an MSI's ProductCode. Today it copies
ProductCode (and any Apps & Features DisplayVersion) unchanged from the
previous version, and check does not notice, so an automated harrier
version would carry the old release's code. An option for it — an addition,
so within ADR 0004 — is to be filed once #3's manifest shows exactly which
fields change.
tools/setup-submitter jeff/harrier, run by an administrator, to give it
WINGET_BOT_TOKEN.
A winget job in its release.yaml like clipwatch's, with the new option
passed through jeff/winget-submit.

Once `winget-submit` exists (#4), each program's release workflow calls it after a release is published, so that a new version reaches the source without a hand-written pull request. - ~~**clipwatch**~~: done. Its `release.yml` has a `winget` job (jeff/clipwatch#2), and v0.2.1 was the first version submitted by itself (#13). - **harrier**: its `release.yaml` builds the MSI on a `v<version>` tag; submit `JCOllie.Harrier` once it has a first, hand-written version (#3). Only tagged, non-prerelease releases are submitted, with `PackageVersion` the tag without its leading `v`. A rolling prerelease such as zettacom's never is: it has no stable hash to pin. Each program repository needs the `winget-bot` token as a secret, and pins `winget-submit` by commit. ## What harrier still needs 1. Its first version, written by hand (#3). 2. `wingetsource new-version` to update an MSI's `ProductCode`. Today it copies `ProductCode` (and any Apps & Features `DisplayVersion`) unchanged from the previous version, and `check` does not notice, so an automated harrier version would carry the old release's code. An option for it — an addition, so within ADR 0004 — is to be filed once #3's manifest shows exactly which fields change. 3. `tools/setup-submitter jeff/harrier`, run by an administrator, to give it `WINGET_BOT_TOKEN`. 4. A `winget` job in its `release.yaml` like clipwatch's, with the new option passed through `jeff/winget-submit`.

jeff added a new dependency

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

#4 winget-submit action and winget-bot user

jeff added a new dependency

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

#3 Add harrier as an MSI package

jeff changed title from ~~Submit new versions from clipwatch's and harrier's release workflows~~ to Submit new versions from harrier's release workflow

2026-10-14 02:41:45 -05:00

jeff commented

2026-10-14 02:41:45 -05:00

Author

Owner

Narrowed to harrier: clipwatch's half is done (jeff/clipwatch#2, first automated submission #13). harrier is blocked on #3 and on new-version learning to update an MSI's ProductCode; see the list in the description.