public/tea
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

ci: add release workflow for Mirus-tagged builds #2

Closed
jmz wants to merge 1 commit from maximus/ci/release-workflow into main
pull from: maximus/ci/release-workflow
merge into: public:main
Conversation 1 Commits 1 Files changed 1 +138
jmz commented 2026-05-06 22:54:48 +00:00
Owner
Copy link

Summary

Adds .forgejo/workflows/release.yml for the local Mirus Tech tea fork. Triggers on tags matching v*+mirus.*, builds tea for linux/arm64 + linux/amd64, uploads tarballs + sha256 manifest as Forgejo Release assets.

Tag scheme

v<upstream>+mirus.<n> — full SemVer 2.0 with build metadata.

Tag Meaning
v0.14.0+mirus.1 First Mirus build of upstream 0.14.0
v0.14.0+mirus.2 Next Mirus build, same upstream (added another patch)
v0.14.1+mirus.1 Restart counter when upstream releases 0.14.1

Why this scheme:

  • Hyphen alternative (v0.14.0-mirus.1) sorts as a pre-release per SemVer (< v0.14.0). Wrong: we're patching, conceptually after.
  • Custom format (mirus-v0.14.0.1) loses semver compatibility — git tag --sort=v:refname won't sort it.
  • + build metadata is the textbook SemVer answer for "same source, distribution-specific build". Forgejo URL-encodes + as %2B automatically.

Asset naming

tea-<version>-linux-<arch>.tar.gz — the executable inside each tarball is just tea, drop-in compatible with anyone scripting against the binary. Distinguishing happens at the asset filename level.

Job behaviour

  1. Checks out at full depth.
  2. Verifies $GITHUB_SHA is reachable from origin/main — tags pushed to non-main commits fail early.
  3. Sets up Go via actions/setup-go@v5 (proven on rpi5 by PR #1's CI fix).
  4. Cross-compiles for arm64 + amd64.
  5. Generates checksum manifest.
  6. Idempotent release creation (POST or fetch existing by tag) + asset upload via Forgejo API.

Prerequisites for first release

  • FORGEJO_TOKEN repo secret with write:repository scope. Provisioned manually; doesn't exist yet on this repo. The workflow fails fast if missing.

How to cut a release

git tag -a v0.14.0+mirus.1 -m "Mirus build 1: FF-only style + --delete-branch"
git push origin v0.14.0+mirus.1

Then watch actions/runs on the fork. The release page lands at /public/tea/releases/tag/v0.14.0%2Bmirus.1.

Not in this PR

  • Provisioning the FORGEJO_TOKEN secret (manual step, awaiting reviewer).
  • A RELEASING.md doc — happy to add as a follow-up if useful.
  • Release-on-merge auto-tagging — releases stay manual for now (user controls the version bump).
## Summary Adds `.forgejo/workflows/release.yml` for the local Mirus Tech tea fork. Triggers on tags matching `v*+mirus.*`, builds tea for linux/arm64 + linux/amd64, uploads tarballs + sha256 manifest as Forgejo Release assets. ## Tag scheme **`v<upstream>+mirus.<n>`** — full SemVer 2.0 with build metadata. | Tag | Meaning | |---|---| | `v0.14.0+mirus.1` | First Mirus build of upstream 0.14.0 | | `v0.14.0+mirus.2` | Next Mirus build, same upstream (added another patch) | | `v0.14.1+mirus.1` | Restart counter when upstream releases 0.14.1 | Why this scheme: - **Hyphen alternative** (`v0.14.0-mirus.1`) sorts as a *pre-release* per SemVer (`< v0.14.0`). Wrong: we're patching, conceptually after. - **Custom format** (`mirus-v0.14.0.1`) loses semver compatibility — `git tag --sort=v:refname` won't sort it. - **`+` build metadata** is the textbook SemVer answer for "same source, distribution-specific build". Forgejo URL-encodes `+` as `%2B` automatically. ## Asset naming `tea-<version>-linux-<arch>.tar.gz` — the executable inside each tarball is just `tea`, drop-in compatible with anyone scripting against the binary. Distinguishing happens at the asset filename level. ## Job behaviour 1. Checks out at full depth. 2. Verifies `$GITHUB_SHA` is reachable from `origin/main` — tags pushed to non-main commits fail early. 3. Sets up Go via `actions/setup-go@v5` (proven on rpi5 by PR #1's CI fix). 4. Cross-compiles for arm64 + amd64. 5. Generates checksum manifest. 6. Idempotent release creation (POST or fetch existing by tag) + asset upload via Forgejo API. ## Prerequisites for first release - `FORGEJO_TOKEN` repo secret with `write:repository` scope. Provisioned manually; doesn't exist yet on this repo. The workflow fails fast if missing. ## How to cut a release ```bash git tag -a v0.14.0+mirus.1 -m "Mirus build 1: FF-only style + --delete-branch" git push origin v0.14.0+mirus.1 ``` Then watch `actions/runs` on the fork. The release page lands at `/public/tea/releases/tag/v0.14.0%2Bmirus.1`. ## Not in this PR - Provisioning the `FORGEJO_TOKEN` secret (manual step, awaiting reviewer). - A `RELEASING.md` doc — happy to add as a follow-up if useful. - Release-on-merge auto-tagging — releases stay manual for now (user controls the version bump).
Triggers on tags matching `v*+mirus.*` (SemVer 2.0 build metadata).
Builds tea for linux/arm64 (rpi5) and linux/amd64 (nas, dev), uploads
the tarballs + a sha256 manifest as Forgejo Release assets.

Tag scheme rationale: `v0.14.0+mirus.1` is "the same release as
upstream 0.14.0 with identifying build metadata". SemVer says build
metadata MUST be ignored when determining version precedence, so it
sorts equivalent to v0.14.0 — correct, since the source semantics are
the same. The `+` is URL-encoded to %2B by Forgejo automatically.

Hyphen alternatives (e.g. `v0.14.0-mirus.1`) sort as pre-releases per
SemVer (`< v0.14.0`), which is wrong for our case.

The executable inside each tarball is named `tea` — drop-in compatible
with scripts that call `tea` directly. Distinguishing by build happens
at the asset filename level, not the binary level.

Job restricts releases to commits reachable from main: a tag pushed
to a non-main commit fails the verify step early.

Token: FORGEJO_TOKEN must be configured as a repo or org secret with
write:repository scope. Provisioned manually for public/tea; rotate
if leaked.
jmz closed this pull request 2026-05-06 23:29:13 +00:00
jmz commented 2026-05-06 23:29:22 +00:00
Author
Owner
Copy link

Closing in favour of model A architecture — main stays a clean upstream mirror, local patches accumulate on a long-lived release/mirus branch, releases are tagged there. The replacement PR will target release/mirus.

Closing in favour of **model A** architecture — `main` stays a clean upstream mirror, local patches accumulate on a long-lived `release/mirus` branch, releases are tagged there. The replacement PR will target `release/mirus`.

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
public/tea!2
No description provided.