Decouple upstream tag from our published version to support rebuilds like v0.7.3.1 #3

New issue

Closed

opened 2026-10-25 02:54:07 -07:00 by oap · 0 comments

oap commented

2026-10-25 02:54:07 -07:00

Owner

Problem

`$VERSION` currently does double duty in `.forgejo/workflows/release.yaml`:
it's both "the upstream tag to `git clone --branch`" and "the tag we
publish our own release under." That breaks two things:

Can't rebuild with a local-only change under a new version. Upstream
only ever has tags like `v0.7.3`, never `v0.7.3.1`. Passing
`v0.7.3.1` as the version input would fail outright at the checkout
step (`git clone --branch v0.7.3.1 ...`), since no such branch/tag
exists upstream.
Re-running the workflow for an existing upstream version is a no-op.
The "Publish release" step exits early if the release tag already
exists ("release $VERSION already exists; keeping its assets"), so a
patch added to `patches/` (see #2) can't actually get published for a
version that's already been built, short of deleting the existing
release first.

Even once published, the installed TV's Homebrew Channel won't see a
rebuilt-but-same-version ipk as an update, since its own update check
compares version strings and nothing changed there.

Proposed fix

Decouple "upstream tag to build from" (keep `$VERSION` meaning this,
unchanged) from "version we publish as" (a new, derived value - e.g.
`${VERSION}.N` for the Nth local rebuild of that upstream tag). Extend
the existing "Point the manifest at our Forgejo" step (which already
rewrites `iconUri`/`sourceUrl`) to also rewrite the manifest's
`version` field to this derived version, since that's most likely what
Homebrew Channel's update-available check reads.

Open question - needs verification on a real TV

Not clear whether the app's update check looks only at the repository
index's manifest version, or also cross-checks something baked into the
ipk itself (the ipk's own `control` file and `appinfo.json` would still
say the unmodified upstream version, e.g. `0.7.3`, since those come from
upstream's build and aren't currently patched). If it's the former this
is a clean, contained change; if it cross-checks, patching those
in-ipk files too would be more invasive and should be scoped as a
follow-up once confirmed.

Prompted by #2 (dropbear password-auth patch): that patch has no way to
reach an already-built release without this.

## Problem \`$VERSION\` currently does double duty in \`.forgejo/workflows/release.yaml\`: it's both "the upstream tag to \`git clone --branch\`" and "the tag we publish our own release under." That breaks two things: 1. **Can't rebuild with a local-only change under a new version.** Upstream only ever has tags like \`v0.7.3\`, never \`v0.7.3.1\`. Passing \`v0.7.3.1\` as the version input would fail outright at the checkout step (\`git clone --branch v0.7.3.1 ...\`), since no such branch/tag exists upstream. 2. **Re-running the workflow for an existing upstream version is a no-op.** The "Publish release" step exits early if the release tag already exists ("release \$VERSION already exists; keeping its assets"), so a patch added to \`patches/\` (see #2) can't actually get published for a version that's already been built, short of deleting the existing release first. Even once published, the installed TV's Homebrew Channel won't see a rebuilt-but-same-version ipk as an update, since its own update check compares version strings and nothing changed there. ## Proposed fix Decouple "upstream tag to build from" (keep \`\$VERSION\` meaning this, unchanged) from "version we publish as" (a new, derived value - e.g. \`${VERSION}.N\` for the Nth local rebuild of that upstream tag). Extend the existing "Point the manifest at our Forgejo" step (which already rewrites \`iconUri\`/\`sourceUrl\`) to also rewrite the manifest's \`version\` field to this derived version, since that's most likely what Homebrew Channel's update-available check reads. ## Open question - needs verification on a real TV Not clear whether the app's update check looks *only* at the repository index's manifest version, or also cross-checks something baked into the ipk itself (the ipk's own \`control\` file and \`appinfo.json\` would still say the unmodified upstream version, e.g. \`0.7.3\`, since those come from upstream's build and aren't currently patched). If it's the former this is a clean, contained change; if it cross-checks, patching those in-ipk files too would be more invasive and should be scoped as a follow-up once confirmed. ## Related Prompted by #2 (dropbear password-auth patch): that patch has no way to reach an already-built release without this.

oap referenced this issue from a commit

2026-10-25 03:17:01 -07:00

feat: publish rebuilds of an upstream tag as v0.7.3.N

oap referenced this issue from a pull request that will close it,

2026-10-25 03:17:18 -07:00

feat: publish rebuilds of an upstream tag as v0.7.3.N #4

oap closed this issue

2026-10-25 03:18:19 -07:00

oap referenced this issue

2026-10-25 03:35:25 -07:00

feat: build the Jellyfin clients and YouTube AdFree from our mirrors #6