ci: add Forgejo-specific workflows to main (operational config for tag-triggered releases) #4

Merged

jmz merged 3 commits from maximus/ci/forgejo-workflows-on-main into main

2026-05-06 23:43:42 +00:00

jmz commented

2026-05-06 23:42:52 +00:00

Owner

Why this lands on main (carve-out from strict model A)

Forgejo Actions only triggers push/tag-push workflows from files on the default branch. The Mirus release pipeline tags v*+mirus.* on the long-lived release/mirus branch, but those tag pushes can't fire any workflow unless .forgejo/workflows/release.yml lives on main. Verified empirically: tag v0.14.0+mirus.1 pushed earlier today fired zero workflow runs.

The carve-out is narrow:

.forgejo/workflows/ is Forgejo-specific operational config. Upstream Gitea uses .gitea/workflows/, which we leave untouched. So this directory's existence on main is not a divergence in upstream-tracked content.
git diff upstream/main main -- ':!.forgejo/' stays empty.
Renovate-driven upstream sync PRs touch .gitea/workflows/, cmd/, modules/, etc. — never .forgejo/.

What's added

.forgejo/workflows/check.yml — shadows the upstream .gitea/workflows/test-pr.yml (which fails on our infra: runs-on: ubuntu-latest + services: gitea-in-docker). Runs clean → vet → build on runs-on: self-hosted. Forgejo prefers .forgejo/workflows/ over .gitea/workflows/, so the upstream YAML is untouched but ignored on our infra.
.forgejo/workflows/release.yml — triggers on tags matching v*+mirus.*. Verifies the tag commit is reachable from release/mirus, builds tea for linux/arm64 + linux/amd64, uploads tarballs + sha256 manifest as Forgejo Release assets. Uses the auto-provided GITHUB_TOKEN (no manual secret).

Tag scheme (recap)

v<upstream>+mirus.<n> — full SemVer 2.0 build metadata. E.g. v0.14.0+mirus.1 is the first Mirus build of upstream 0.14.0.

Test plan

check.yml already proven on release/mirus PR #3 (CI run 1476 success).
After merge, re-push the existing v0.14.0+mirus.1 tag to trigger release.yml. Verify build for both arches and Release page lands at /public/tea/releases/tag/v0.14.0%2Bmirus.1.

Refs

Closed PR #1 (--delete-branch flag, redirected to PR #3 against release/mirus)
Closed PR #2 (release-workflow, redirected to this PR)
Merged PR #3 (--delete-branch flag landed on release/mirus)

## Why this lands on main (carve-out from strict model A) Forgejo Actions only triggers push/tag-push workflows from files on the **default branch**. The Mirus release pipeline tags `v*+mirus.*` on the long-lived `release/mirus` branch, but those tag pushes can't fire any workflow unless `.forgejo/workflows/release.yml` lives on `main`. Verified empirically: tag `v0.14.0+mirus.1` pushed earlier today fired zero workflow runs. The carve-out is narrow: - `.forgejo/workflows/` is **Forgejo-specific operational config**. Upstream Gitea uses `.gitea/workflows/`, which we leave untouched. So this directory's existence on `main` is *not* a divergence in upstream-tracked content. - `git diff upstream/main main -- ':!.forgejo/'` stays empty. - Renovate-driven upstream sync PRs touch `.gitea/workflows/`, `cmd/`, `modules/`, etc. — never `.forgejo/`. ## What's added - **`.forgejo/workflows/check.yml`** — shadows the upstream `.gitea/workflows/test-pr.yml` (which fails on our infra: `runs-on: ubuntu-latest` + `services: gitea-in-docker`). Runs `clean → vet → build` on `runs-on: self-hosted`. Forgejo prefers `.forgejo/workflows/` over `.gitea/workflows/`, so the upstream YAML is untouched but ignored on our infra. - **`.forgejo/workflows/release.yml`** — triggers on tags matching `v*+mirus.*`. Verifies the tag commit is reachable from `release/mirus`, builds tea for linux/arm64 + linux/amd64, uploads tarballs + sha256 manifest as Forgejo Release assets. Uses the auto-provided `GITHUB_TOKEN` (no manual secret). ## Tag scheme (recap) `v<upstream>+mirus.<n>` — full SemVer 2.0 build metadata. E.g. `v0.14.0+mirus.1` is the first Mirus build of upstream 0.14.0. ## Test plan - [x] `check.yml` already proven on `release/mirus` PR #3 (CI run 1476 success). - [ ] After merge, re-push the existing `v0.14.0+mirus.1` tag to trigger `release.yml`. Verify build for both arches and Release page lands at `/public/tea/releases/tag/v0.14.0%2Bmirus.1`. ## Refs - Closed PR #1 (`--delete-branch` flag, redirected to PR #3 against `release/mirus`) - Closed PR #2 (release-workflow, redirected to this PR) - Merged PR #3 (`--delete-branch` flag landed on `release/mirus`)

jmz added 3 commits

2026-05-06 23:42:52 +00:00

ci: add check.yml + release.yml workflows for the Mirus release line 27bdb50c27

Both workflows live on this branch (release/mirus), not on main. Per
the model-A architecture for this fork: main stays a clean upstream
mirror; local infrastructure (CI shadowing the broken upstream
test-pr.yml, release pipeline) lives here so PRs against release/mirus
get tested + tagged builds get artifacts.

- check.yml: shadow of the broken upstream .gitea/workflows/test-pr.yml.
  Forgejo prefers .forgejo/workflows/ when both are present, so the
  upstream YAML stays untouched (clean upstream sync) but is ignored.
  Job: clean → vet → build, runs-on self-hosted (rpi5).

- release.yml: triggers on tags v*+mirus.* (SemVer 2.0 build metadata).
  Builds tea for linux/arm64 + linux/amd64, uploads tarballs +
  sha256 manifest as Forgejo Release assets. Verifies the tag commit
  is on release/mirus before building (rejects misplaced tags early).

Files unchanged from PR #1's check.yml + PR #2's release.yml; closed
those PRs in favour of this consolidated landing on release/mirus.

ci: target release/mirus (not main) for release ancestor check (model A) abf0cacb00

ci: use auto-provided GITHUB_TOKEN for release workflow

check / check (pull_request) Successful in 30s

Details

check / check (push) Successful in 39s

Details

a428d184df

Forgejo (like GitHub Actions) provides `secrets.GITHUB_TOKEN` per run
with write scope on the running repo. Eliminates the manual
FORGEJO_TOKEN provisioning step. If a longer-lived or cross-repo token
is ever needed, swap back to a named secret.

jmz merged commit a428d184df into main

2026-05-06 23:43:42 +00:00

jmz referenced this pull request

2026-05-06 23:47:59 +00:00

ci(release): fix tag pattern — Forgejo treats + as special, not literal #5