Bosco/bosco

Fork 0

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

New issue

Closed

opened 2026-08-03 16:49:41 +00:00 by manlycucumber · 2 comments

manlycucumber commented

2026-08-03 16:49:41 +00:00

Owner

What's wrong

release-please / release-please (push) fails on every push to develop. It has never succeeded on this Forgejo instance, and it never will.

This is not a regression and not a token problem. It is an unfinished migration.

Why

This repo was imported from GitHub on 2026-07-11 — Forgejo still records original_url = https://github.com/BoscoApp/bosco.git. It came across with its GitHub release automation intact and nobody ported it:

.github/workflows/release-please.yml (targets develop, googleapis/release-please-action@v4)
release-please-config.json (release-type: node, package-name: bosco, bump-minor-pre-major: true)
.release-please-manifest.json (0.3.0)

Everything that looks like release-please working here is imported history. v0.1.0 and v0.2.0 show their author as Ghost — Forgejo's placeholder for an unmapped GitHub actor, i.e. github-actions[bot] on the old host. The release-please--branches--develop--components--bosco branch is likewise imported; its head commit f3d22f25 chore(develop): release 0.3.0 is dated 2026-07-12 but was authored on GitHub. v0.3.0 (2026-07-18) was cut by hand — its author is manlycucumber, not a bot.

The workflow sets no github-api-url, so it authenticates a Forgejo token against api.github.com and gets Bad credentials — docs.github.com/rest. Repointing the REST base URL would not save it either: release-please's commit, PR and release iterators are GraphQL queries, and Forgejo exposes no GraphQL endpoint at all (/api/graphql, /graphql and /api/v1/graphql all 404 while /api/v1/version returns 200).

What to do instead

The estate already answered this. manlycucumber/tier-kit ships cliff.toml and .forgejo/workflows/release.yml, whose own header reads "Forgejo Full-tier release automation (replaces GitHub release-please)". manlycucumber/arx runs it today. This repo has no .forgejo/workflows directory at all.

The port:

Add cliff.toml and .forgejo/workflows/release.yml from the tier-kit.
Delete .github/workflows/release-please.yml, release-please-config.json, .release-please-manifest.json.
Retire the now-dead release-please labels if any are in use.

Two things that will bite

Branch mismatch. The tier-kit workflow is on: push: branches: [main]. This repo releases from develop (that is what target-branch: develop means in the current config). Either retarget the workflow to develop or decide that main becomes the release branch — a real choice, not a find-and-replace, because main is currently behind and branch protection is applied.
RELEASE_TOKEN is not set. The workflow needs a repo or org secret RELEASE_TOKEN — a Forgejo token with write:repository belonging to the maintainer. GET /repos/Bosco/bosco/actions/secrets currently returns none. If the release branch is protected, whitelist that user for push in the protection rule.

State at time of writing (2026-08-03)

ci / ci (push) on 13c85aa8 is green — the first successful CI run this repo has ever had, after the Forgejo Actions mirror fault was fixed on jerome at 14:36 today (DEFAULT_ACTIONS_URL pointed at data.forgejo.org, which mirrors only actions/*, so every third-party uses: 404'd and every job died at "Set up job"). release-please / release-please (push) is the only remaining red check, and it fails in 3 seconds on Bad credentials.

So the only thing standing between this repo and an all-green develop is this migration.

## What's wrong `release-please / release-please (push)` fails on every push to `develop`. It has **never** succeeded on this Forgejo instance, and it never will. This is not a regression and not a token problem. It is an unfinished migration. ## Why This repo was **imported from GitHub on 2026-07-11** — Forgejo still records `original_url = https://github.com/BoscoApp/bosco.git`. It came across with its GitHub release automation intact and nobody ported it: - `.github/workflows/release-please.yml` (targets `develop`, `googleapis/release-please-action@v4`) - `release-please-config.json` (`release-type: node`, `package-name: bosco`, `bump-minor-pre-major: true`) - `.release-please-manifest.json` (`0.3.0`) Everything that looks like release-please working here is imported history. `v0.1.0` and `v0.2.0` show their author as **`Ghost`** — Forgejo's placeholder for an unmapped GitHub actor, i.e. `github-actions[bot]` on the old host. The `release-please--branches--develop--components--bosco` branch is likewise imported; its head commit `f3d22f25 chore(develop): release 0.3.0` is dated 2026-07-12 but was authored on GitHub. **`v0.3.0` (2026-07-18) was cut by hand** — its author is `manlycucumber`, not a bot. The workflow sets no `github-api-url`, so it authenticates a *Forgejo* token against `api.github.com` and gets `Bad credentials — docs.github.com/rest`. Repointing the REST base URL would not save it either: release-please's commit, PR and release iterators are **GraphQL** queries, and Forgejo exposes no GraphQL endpoint at all (`/api/graphql`, `/graphql` and `/api/v1/graphql` all 404 while `/api/v1/version` returns 200). ## What to do instead The estate already answered this. `manlycucumber/tier-kit` ships `cliff.toml` and `.forgejo/workflows/release.yml`, whose own header reads *"Forgejo Full-tier release automation (replaces GitHub release-please)"*. `manlycucumber/arx` runs it today. This repo has **no `.forgejo/workflows` directory at all**. The port: 1. Add `cliff.toml` and `.forgejo/workflows/release.yml` from the tier-kit. 2. Delete `.github/workflows/release-please.yml`, `release-please-config.json`, `.release-please-manifest.json`. 3. Retire the now-dead release-please labels if any are in use. ### Two things that will bite - **Branch mismatch.** The tier-kit workflow is `on: push: branches: [main]`. This repo releases from `develop` (that is what `target-branch: develop` means in the current config). Either retarget the workflow to `develop` or decide that `main` becomes the release branch — a real choice, not a find-and-replace, because `main` is currently behind and branch protection is applied. - **`RELEASE_TOKEN` is not set.** The workflow needs a repo or org secret `RELEASE_TOKEN` — a Forgejo token with `write:repository` belonging to the maintainer. `GET /repos/Bosco/bosco/actions/secrets` currently returns none. If the release branch is protected, whitelist that user for push in the protection rule. ## State at time of writing (2026-08-03) `ci / ci (push)` on `13c85aa8` is **green** — the first successful CI run this repo has ever had, after the Forgejo Actions mirror fault was fixed on jerome at 14:36 today (`DEFAULT_ACTIONS_URL` pointed at `data.forgejo.org`, which mirrors only `actions/*`, so every third-party `uses:` 404'd and every job died at "Set up job"). `release-please / release-please (push)` is the only remaining red check, and it fails in 3 seconds on `Bad credentials`. So the *only* thing standing between this repo and an all-green develop is this migration.

manlycucumber added the

area: infra

label

2026-08-03 16:49:41 +00:00

manlycucumber referenced this issue from a commit

2026-08-03 16:55:42 +00:00

docs(forgejo): record the actions-mirror fix and the two GitHub-isms it exposed

manlycucumber commented

2026-08-03 19:38:11 +00:00

Author

Owner

Evidence for the decision, from a live run rather than from reasoning about it.

Bosco/bosco run 52 (task 2233, 2026-08-03 14:44), with the action mirror fixed so the action itself now fetches cleanly from github.com:

☁️  git fetch 'https://github.com/googleapis/release-please-action' # ref=v4
⭐ Run Main googleapis/release-please-action@v4
Running release-please version: 17.3.0
❯ Fetching release-please-config.json from branch develop
✔ Building releases
✔ Collecting release commit SHAs
❯ release search depth: 400
❯ Fetching releases with cursor undefined
::error::release-please failed: Bad credentials - https://docs.github.com/rest

It reads the repo fine — it fetched the config and the manifest off develop — and then dies asking api.github.com for the release history. Bad credentials is not a token that needs rotating: it is the wrong service. release-please is an Octokit client against GitHub's REST/GraphQL API, and no Forgejo token will ever satisfy it.

So this is not "works but misconfigured". It cannot work here, and every push to develop will keep failing this check until the workflow is gone.

Scope is wider than this repo. Seven still carry release-please.yml:

Bosco/bosco (this issue)
Imaginook/Imaginook (#831 there)
Directorium/Api, Directorium/Core, Directorium/Ordo, Directorium/Site
3MI/Ordo

The four Directorium repos and 3MI/Ordo have no issue filed. The Directorium ones only trigger on main, so they are quiet today and will fail the moment anything is promoted.

The estate already has the answer in manlycucumber/tier-kit: the Full tier ships a git-cliff release.yml plus cliff.toml, which is Forgejo-native. Porting is a copy of that, not a design.

One caveat before copying: tier-kit's own release.yml has been red on main since 2026-07-20, as has arx's. Worth confirming the canonical one actually passes before it is propagated to seven repos.

Evidence for the decision, from a live run rather than from reasoning about it. `Bosco/bosco` run 52 (task 2233, 2026-08-03 14:44), with the action mirror fixed so the action itself now fetches cleanly from github.com: ``` ☁️ git fetch 'https://github.com/googleapis/release-please-action' # ref=v4 ⭐ Run Main googleapis/release-please-action@v4 Running release-please version: 17.3.0 ❯ Fetching release-please-config.json from branch develop ✔ Building releases ✔ Collecting release commit SHAs ❯ release search depth: 400 ❯ Fetching releases with cursor undefined ::error::release-please failed: Bad credentials - https://docs.github.com/rest ``` It reads the repo fine — it fetched the config and the manifest off `develop` — and then dies asking **api.github.com** for the release history. `Bad credentials` is not a token that needs rotating: it is the wrong service. release-please is an Octokit client against GitHub's REST/GraphQL API, and no Forgejo token will ever satisfy it. So this is not "works but misconfigured". It cannot work here, and every push to `develop` will keep failing this check until the workflow is gone. **Scope is wider than this repo.** Seven still carry `release-please.yml`: - `Bosco/bosco` (this issue) - `Imaginook/Imaginook` (#831 there) - `Directorium/Api`, `Directorium/Core`, `Directorium/Ordo`, `Directorium/Site` - `3MI/Ordo` The four Directorium repos and `3MI/Ordo` have no issue filed. The Directorium ones only trigger on `main`, so they are quiet today and will fail the moment anything is promoted. The estate already has the answer in `manlycucumber/tier-kit`: the Full tier ships a git-cliff `release.yml` plus `cliff.toml`, which is Forgejo-native. Porting is a copy of that, not a design. One caveat before copying: `tier-kit`'s own `release.yml` has been red on `main` since 2026-07-20, as has `arx`'s. Worth confirming the canonical one actually passes before it is propagated to seven repos.

manlycucumber commented

2026-08-04 15:44:14 +00:00

Author

Owner

Pre-port check cleared for this repo

tier-kit#8 asks that the wrapped-subject count check be run against a repo's history before porting it, because a repo carrying hard-wrapped commit subjects produces a first release that silently under-reports — no warning, no signal in the job output, and a shorter changelog reads as "a quiet release" rather than as a fault.

Ran it against Bosco/bosco. Clear.


commits on `develop`	40
commits carrying a multi-line body	31
hard-wrapped subjects	0
non-conventional subjects	1 — `7e8ad847 Initial empty repository`, the root commit
last tag	`v0.3.0` (8 commits since)

The 31 multi-line bodies matter: they are what shows the check was genuinely exercised rather than matching nothing. Method, the control run against arx, and the full results for all seven repos are in tier-kit#8.

So the silent-drop hazard does not apply here, and it does not gate this port. The two obstacles named in the issue body above are unaffected and remain the real work:

branch mismatch — this repo releases from develop; the tier-kit workflow fires on: push: branches: [main]. Still a genuine decision, not a find-and-replace.
RELEASE_TOKEN is unset — still returns no secrets.

One thing the check did surface that is worth knowing when the first git-cliff release is cut here: v0.3.0 was tagged by hand and there are 8 commits after it, so the first automated run will compute its bump from those 8 alone.

## Pre-port check cleared for this repo tier-kit#8 asks that the wrapped-subject count check be run against a repo's history **before** porting it, because a repo carrying hard-wrapped commit subjects produces a first release that silently under-reports — no warning, no signal in the job output, and a shorter changelog reads as "a quiet release" rather than as a fault. Ran it against `Bosco/bosco`. **Clear.** | | | |---|---| | commits on `develop` | 40 | | commits carrying a multi-line body | 31 | | **hard-wrapped subjects** | **0** | | non-conventional subjects | 1 — `7e8ad847 Initial empty repository`, the root commit | | last tag | `v0.3.0` (8 commits since) | The 31 multi-line bodies matter: they are what shows the check was genuinely exercised rather than matching nothing. Method, the control run against arx, and the full results for all seven repos are in tier-kit#8. So the silent-drop hazard does not apply here, and it does not gate this port. The two obstacles named in the issue body above are unaffected and remain the real work: - **branch mismatch** — this repo releases from `develop`; the tier-kit workflow fires `on: push: branches: [main]`. Still a genuine decision, not a find-and-replace. - **`RELEASE_TOKEN` is unset** — still returns no secrets. One thing the check did surface that is worth knowing when the first git-cliff release is cut here: `v0.3.0` was tagged by hand and there are 8 commits after it, so the first automated run will compute its bump from those 8 alone.

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

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

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

manlycucumber closed this issue

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

manlycucumber referenced this issue

2026-08-14 22:09:15 +00:00

Release flow now points at main but has never run there — prove it before v0.4.0 #116