ci(release): port release automation off release-please to the tier-kit git-cliff flow #117

Merged

manlycucumber merged 1 commit from ci/port-release-automation into develop

2026-08-05 15:22:28 +00:00

manlycucumber commented

2026-08-05 14:43:11 +00:00

Owner

release-please has never succeeded on this Forgejo instance and never will — the repo came over from GitHub with its release automation intact and nobody ported it. It authenticates a Forgejo token against api.github.com ("Bad credentials"), and repointing the REST base would not help because release-please's commit/PR/release iterators are GraphQL, which Forgejo does not expose at all. The tags that make it look like it once worked are imported history, authored by Ghost.

This replaces it with the flow manlycucumber/arx has run in production since v0.1.0:

cliff.toml — Conventional Commits → SemVer, via git-cliff
.forgejo/workflows/release.yml — computes the bump, tags vX.Y.Z, creates the Forgejo Release
scripts/changelog.sh — regenerates CHANGELOG.md locally

…and deletes .github/workflows/release-please.yml, release-please-config.json and .release-please-manifest.json.

Taken from tier-kit `develop`, not `main` — deliberately

tier-kit's main is still v0.1.2, which predates a6c768b ("the two halves agree on a first version"). Without it, changelog.sh and release.yml disagree on a repo's first version: git-cliff inherits the v prefix from the previous tag and has none on a first release, so the changelog is headed 0.1.0 against a v0.1.0 tag. That bites only on a first release — which is exactly what this port produces here. Porting from main would have shipped that bug.

This repo

Release fires on push to main, matching where it already released from. The job never writes to the branch: a runner holds no signing key, so a CHANGELOG commit made there lands unverified — hence the local changelog.sh half.

Before this can cut a release

RELEASE_TOKEN repo secret — a Forgejo token with write:repository belonging to the maintainer.
If a v* tag protection rule exists, that user must be whitelisted on it, or the tag push is refused.

Checked before porting

Ran tier-kit#8's count check against this repo's history: no hard-wrapped commit subjects, so nothing will be silently dropped from the first release notes or from the version bump. Full results for all seven repos are in tier-kit#8.

`release-please` has never succeeded on this Forgejo instance and never will — the repo came over from GitHub with its release automation intact and nobody ported it. It authenticates a Forgejo token against `api.github.com` ("Bad credentials"), and repointing the REST base would not help because release-please's commit/PR/release iterators are **GraphQL**, which Forgejo does not expose at all. The tags that make it look like it once worked are imported history, authored by `Ghost`. This replaces it with the flow `manlycucumber/arx` has run in production since v0.1.0: - `cliff.toml` — Conventional Commits → SemVer, via git-cliff - `.forgejo/workflows/release.yml` — computes the bump, tags `vX.Y.Z`, creates the Forgejo Release - `scripts/changelog.sh` — regenerates `CHANGELOG.md` locally …and deletes `.github/workflows/release-please.yml`, `release-please-config.json` and `.release-please-manifest.json`. ### Taken from tier-kit `develop`, not `main` — deliberately tier-kit's `main` is still v0.1.2, which **predates** `a6c768b` ("the two halves agree on a first version"). Without it, `changelog.sh` and `release.yml` disagree on a repo's first version: git-cliff inherits the `v` prefix from the previous tag and has none on a first release, so the changelog is headed `0.1.0` against a `v0.1.0` tag. That bites **only** on a first release — which is exactly what this port produces here. Porting from `main` would have shipped that bug. ### This repo Release fires on push to **`main`**, matching where it already released from. The job never writes to the branch: a runner holds no signing key, so a CHANGELOG commit made there lands unverified — hence the local `changelog.sh` half. ### Before this can cut a release - **`RELEASE_TOKEN`** repo secret — a Forgejo token with `write:repository` belonging to the maintainer. - If a `v*` **tag protection** rule exists, that user must be whitelisted on it, or the tag push is refused. ### Checked before porting Ran tier-kit#8's count check against this repo's history: **no hard-wrapped commit subjects**, so nothing will be silently dropped from the first release notes or from the version bump. Full results for all seven repos are in tier-kit#8.

manlycucumber added 1 commit

2026-08-05 14:43:11 +00:00

ci(release): port release automation off release-please to the tier-kit git-cliff flow 92954ea196

release-please has never succeeded on this Forgejo instance and never will. The
repo was imported from GitHub with its release automation intact and nobody
ported it, so the job has been failing on every push since.

It is not a token problem. The workflow sets no github-api-url, so it
authenticates a Forgejo token against api.github.com and gets "Bad credentials";
and repointing the REST base would not save it either, because release-please's
commit, PR and release iterators are GraphQL and Forgejo exposes no GraphQL
endpoint at all. The tags that make it look like it once worked are imported
history — their author is Ghost, Forgejo's placeholder for an unmapped GitHub
actor.

So: cliff.toml + .forgejo/workflows/release.yml + scripts/changelog.sh from
manlycucumber/tier-kit, which computes the SemVer bump from Conventional Commits
with git-cliff, tags vX.Y.Z and creates the Forgejo Release. manlycucumber/arx
has run it in production since v0.1.0.

Taken from tier-kit DEVELOP (a6c768b), not main. main is still v0.1.2, which
predates the fix for changelog.sh and release.yml disagreeing about a first
version: git-cliff inherits the `v` prefix from the previous tag and has none
on a first release, so the changelog would be headed "0.1.0" against a "v0.1.0"
tag. That only bites on a repo's FIRST release, which is exactly what this port
produces here.

The release job fires on push to main, matching where this repo already
released from. It does NOT write to the branch: a runner has no signing key, so
a CHANGELOG commit made there would land unverified. CHANGELOG.md is regenerated
locally by scripts/changelog.sh and committed, signed, by the maintainer.

Needs a repo or org secret RELEASE_TOKEN — a Forgejo token with write:repository
belonging to the maintainer — and that user whitelisted on any v* tag protection.

Signed-off-by: manlycucumber <manlycucumber@protonmail.com>

manlycucumber merged commit ff67c76a58 into develop

2026-08-05 15:22:28 +00:00

manlycucumber referenced this pull request from a commit

2026-08-05 15:22:28 +00:00

ci(release): port release automation off release-please to the tier-kit git-cliff flow (#117)

manlycucumber referenced this pull request from a commit

2026-08-05 15:44:27 +00:00

ci(release): port release automation off release-please to the tier-kit git-cliff flow (#117)