The previous commit switched to ${{ forgejo.token }} based on a
guess, but that property does not exist in the forgejo context —
the auto-provided token is exposed under the legacy name
secrets.GITHUB_TOKEN (a holdover from the upstream Action runner
codebase). This is documented empirically by
yavsc/.forgejo/workflows/release.yml, which uses this same
expression and works.
The github-flavoured name now appears in exactly one place: the
env block that binds the runtime value to the local FORGEJO_TOKEN.
Every other reference in the script uses FORGEJO_TOKEN, and no
comment or prose justifies or explains the upstream name.
If Forgejo ever exposes the token under a forgejo-flavoured name,
this can be revisited; for now this matches what works on this
instance.
Following up on the previous commit (forgejo.* / FORGEJO_TOKEN
env vars): the previous version still had two carve-outs that
kept github-flavoured names alive in this script, namely
- ${{ secrets.GITHUB_TOKEN }} (token source) -> ${{ forgejo.token }}
- $GITHUB_ENV (inter-step state file) -> /tmp/release-state.env
Both name choices were inherited from yavsc's workflow without
re-checking. Neither is forced by Forgejo; the auto-provided token
is exposed via the forgejo context, and inter-step state can be
persisted via a plain env file sourced at the top of each step.
Result: zero occurrences of 'github' (case-insensitive) anywhere
in .forgejo/workflows/release.yml.
YAML re-validated with yaml.safe_load.
The github context was kept for compatibility in yavsc's
.forgejo/workflows/release.yml, but we don't need that here — the
forgejo context is canonical and we want zero GitHub-flavoured
naming in this script.
- All ${{ github.* }} -> ${{ forgejo.* }}
- Env vars GITHUB_API_URL / GITHUB_REPOSITORY / GITHUB_TOKEN
-> FORGEJO_API_URL / FORGEJO_REPOSITORY / FORGEJO_TOKEN
- The token's source (${{ secrets.GITHUB_TOKEN }}) is the one
exception: that's the runtime variable name exposed by the
upstream Action runner, not a naming choice. A comment in the
env block explains why we read it under the legacy name and
immediately re-bind it to FORGEJO_TOKEN.
- Same for $GITHUB_ENV (inter-step env file): runtime-controlled
name, kept under its technical identity with a note.
YAML re-validated with yaml.safe_load.
- GITHUB_TOKEN expression was sanitized to '*** ... }}' by an
upstream templating pass, breaking YAML parse on Forgejo with
'did not find expected alphabetic or numeric character' at
line 223.
- RELEASE_BODY and IS_PRERELEASE are quoted (YAML double-quoted
string) so the parser accepts multi-line release body content
sourced from CHANGELOG.md.
Verified locally with yaml.safe_load.
The GitHub channel gave nothing but chaos (failed runs on tag push,
auth issues with gh CLI on this side). Forgejo is the source of
truth (cf. USER.md 'Remote setup' for the yavsc mirror setup), so
move the .deb release workflow there.
- Remove .github/workflows/build-and-release-deb.yml.
- Add .forgejo/workflows/release.yml, mirroring the structure of
yavsc/.forgejo/workflows/release.yml (single job, no Node, bash
+ jq + curl). amd64 and arm64 .deb built sequentially (matrix
is impossible because actions/upload-artifact needs Node, which
the runner image pazof/yavsc-build-env doesn't ship — same
constraint as documented in MEMORY.md).
- Reuse existing release on tag collision (PATCH instead of POST)
to keep the /releases/tag/<tag> permalink stable — re-tag = le
mal, but a re-build of the same tag should not duplicate releases.
