ZacharyZhang-NY/Kigi-CLI
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Return the forge to GitHub: releases, self-update, links, CI
Release / build (x86_64-unknown-linux-gnu) (push) Failing after 6s
Details
Release / build (aarch64-apple-darwin) (push) Canceled after 0s
Details
Release / build (aarch64-unknown-linux-gnu) (push) Canceled after 0s
Details
Release / build (x86_64-apple-darwin) (push) Canceled after 0s
Details
Release / build (x86_64-pc-windows-msvc) (push) Canceled after 0s
Details
Release / publish GitHub Release (push) Canceled after 0s
Details

Browse Source 
The GitHub account is restored, so github.com/ZacharyZhang-NY/Kigi-CLI is
the canonical repo again. Reverse the 2026-08 Gitea migration:

- .github/workflows/{release,warm-cache}.yml: restore the GitHub-hosted
  pipeline dropped in 3e1652c, unchanged — hosted runners, rust-cache,
  softprops release with every asset attached atomically.
- .gitea/workflows/release.yml: retire the Gitea edition (the runners are
  being deregistered; git.zacharyzhang.com keeps the v0.1.12/v0.1.13
  releases for old clients).
- kigi-env: update_base_url now defaults to the GitHub Releases API. The
  updater already speaks GitHub wire format and sends a User-Agent; v0.1.14
  is published to BOTH forges with identical assets so pre-0.1.14 installs
  polling Gitea self-update onto the GitHub channel.
- install.sh / install.ps1: resolve releases from api.github.com.
- feedback, /docs, SECURITY.md, frontend worker + site: repo, issues and
  raw-file links point at github.com / raw.githubusercontent.com.
- docs/RELEASE.md: GitHub edition of the checklist; Gitea runner sections
  retired.
- version: 0.1.13 -> 0.1.14 (the cross-forge transition release).

Claude-Session: https://claude.ai/code/session_01A6RcwHhhsFYYrNdQB4ASuP
This commit is contained in:
ZacharyZhang-NY committed 2026-09-01 01:05:22 -04:00
1 parent 39cb1ca1bc
commit f7a4cb64ab
17 files changed
+336 -589
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/RELEASE.md
+25 -133
View File
@@ -1,17 +1,14 @@
# Release checklist (PRD F8)
Kigi ships as a single-file binary for five targets, published on this
repo's Gitea Releases by `.gitea/workflows/release.yml`. Users install via
repo's GitHub Releases by `.github/workflows/release.yml`. Users install via
`install.sh` / `install.ps1` and stay current through the in-app
self-updater (`kigi-update`), which resolves the same Releases API.
`.github/workflows/release.yml` is the retired GitHub pipeline. Gitea ignores
`.github/workflows` entirely whenever `.gitea/workflows` is non-empty, so it
does not run — it is kept only as a reference for the GitHub-hosted layout.
## Cutting a release
1. Bump `[workspace.package] version` in `Cargo.toml`; land the change on
1. Bump `[workspace.package] version` in `Cargo.toml` (and refresh
`Cargo.lock` with `cargo update --workspace`); land the change on
`main` with green CI.
2. Regenerate the third-party notices (not enforced by CI — this is the
step that keeps `THIRD-PARTY-NOTICES.md` fresh):
@@ -34,15 +31,10 @@ does not run — it is kept only as a reference for the GitHub-hosted layout.
`release-dist` profile, packages
`kigi-<version>-<target-triple>.{tar.gz|zip}` archives (binary +
LICENSE + NOTICE + THIRD-PARTY-NOTICES), generates `SHA256SUMS`, and
publishes the Gitea Release. Tags containing `-` (e.g.
`v0.2.0-alpha.1`) publish as pre-releases, which only the `alpha`
update channel picks up.
The release is created as a **draft** and only flipped public once
`SHA256SUMS` is attached, so `releases/latest` never hands the installer
a release whose checksum manifest is still missing. A failed run leaves
the draft in place; re-pushing the tag reuses it rather than erroring on
a duplicate `tag_name`.
publishes the GitHub Release with every asset attached in one step, so
`releases/latest` never serves a release whose checksum manifest is
missing. Tags containing `-` (e.g. `v0.2.0-alpha.1`) publish as
pre-releases, which only the `alpha` update channel picks up.
5. Smoke-test an installed artifact:
```sh
@@ -52,127 +44,27 @@ does not run — it is kept only as a reference for the GitHub-hosted layout.
## Build runners
Gitea has no hosted runners, so all three `runs-on` labels below are machines
we register ourselves with `gitea-runner` (the binary formerly called
`act_runner`). Labels are declared in the runner's `config.yaml` as
`<label>:host` (run directly on the machine) or `<label>:docker://<image>` (run
in a container) — with `gitea-runner` v2, `register --labels` is ignored
whenever a config file supplies them.
All five legs run on GitHub-hosted runners — nothing self-hosted to keep
alive:
| Label | Machine | Mode | Builds |
| ---------------- | ------------------------------ | ------ | -------------------------------------------------- |
| `ubuntu-latest` | the Dokploy box | docker | `x86_64-unknown-linux-gnu`, `aarch64-unknown-linux-gnu` |
| `macos-arm64` | Mac Mini (M4) | host | `aarch64-apple-darwin`, `x86_64-apple-darwin` |
| `windows-x86_64` | ZACHARYZHANG-PC | host | `x86_64-pc-windows-msvc` |
| `runs-on` | Builds |
| ------------------ | ------------------------------------------------------- |
| `macos-14` (arm64) | `aarch64-apple-darwin`, `x86_64-apple-darwin` (cross) |
| `ubuntu-24.04` | `x86_64-unknown-linux-gnu` |
| `ubuntu-24.04-arm` | `aarch64-unknown-linux-gnu` (native) |
| `windows-2022` | `x86_64-pc-windows-msvc` |
The Linux legs use `ubuntu-latest` because that is what the Dokploy box's
runner already advertises. That image is a bare runner-image, so those legs
provision their own apt packages and rustup per run (`rustup show` then picks
up the `rust-toolchain.toml` pin). If you register a dedicated
`linux-x86_64:docker://…` runner later, change the three Linux `runs-on`
values back to match it.
`warm-cache.yml` rebuilds the `release-dist` profile on `main` whenever the
dependency graph changes (plus a weekly refresh), so tag builds restore a
warm default-branch cache instead of compiling the workspace cold. Its setup
steps mirror `release.yml`'s build job — keep them in lockstep, or the cache
key stops matching.
**The Mac is not optional.** Apple's SDK licence limits macOS builds to
Apple-branded hardware, and the Darwin targets need the real Apple linker
anyway (`.cargo/config.toml` passes `-ObjC` and `-undefined dynamic_lookup`).
There is no supported way to produce our macOS artifacts on the Linux server.
One Apple Silicon Mac covers both Darwin targets — `x86_64-apple-darwin` is a
cross-compile against the same SDK, exactly as the old GitHub `macos-14`
runner did it.
Windows is a softer requirement but still wants a real machine: the tree links
`ring`, `mimalloc`, `zstd-sys` and `libz-sys` against a static MSVC CRT
(`-C target-feature=+crt-static`). Cross-compiling that from Linux with
`cargo-xwin` is possible but means debugging four C builds under `clang-cl`;
a Windows runner with the VS 2022 C++ Build Tools reproduces today's binary
exactly.
Linux arm64 *is* cross-compiled on the x86_64 box — the workflow installs
`gcc-aarch64-linux-gnu` and points `cc-rs` at it. The one thing this loses is
the ability to smoke-test the arm64 binary before publishing (the old GitHub
pipeline did not test it either). Register a native arm64 runner and change
that matrix leg's `runner:` if you want it built natively.
### Registering a runner
Get a registration token from **Settings → Actions → Runners** (repo scope),
your user settings (all your repos) or the site admin panel (instance-wide).
Over the API it is a **POST**, not a GET — a GET is parsed as runner id `0` and
404s:
```sh
curl -fsS -X POST -H "Authorization: token $GITEA_API_TOKEN" \
https://git.zacharyzhang.com/api/v1/user/actions/runners/registration-token
```
Write the labels into `config.yaml` first (see `runner.labels` in
`gitea-runner generate-config`), then register on each machine:
```sh
# Linux (the Dokploy box) — container mode
gitea-runner --config config.yaml register --no-interactive \
--instance https://git.zacharyzhang.com \
--token <REGISTRATION_TOKEN> \
--name kigi-linux-x86_64
# macOS (Apple Silicon) — host mode, needs Xcode CLT + rustup + Node on PATH
gitea-runner --config config.yaml register --no-interactive \
--instance https://git.zacharyzhang.com \
--token <REGISTRATION_TOKEN> \
--name kigi-macos-arm64
# Windows — host mode, needs VS 2022 Build Tools + rustup + Node on PATH
gitea-runner --config config.yaml register --no-interactive `
--instance https://git.zacharyzhang.com `
--token <REGISTRATION_TOKEN> `
--name kigi-windows-x86_64
```
Host-mode runners execute steps with the daemon's own environment, so each
needs its build prerequisites installed up front — and the supervisor that
launches the daemon must put them on `PATH`:
- **macOS**: `xcode-select --install`, `rustup`, and Node (for
`actions/checkout`, which is a JavaScript action).
- **Windows**: VS 2022 Build Tools with the "Desktop development with C++"
workload, `rustup`, Git for Windows, and Node. Every Windows step in the
workflow uses `shell: powershell` (5.1) — never `bash`, which on a normal
Windows box resolves to WSL.
- **Linux (docker mode)**: nothing on the host — the workflow installs
`build-essential`, `jq`, `unzip`, protoc, rustup and the cross toolchain
inside the container per run.
### Keeping the runners alive
Each host-mode runner is supervised so it survives reboots and crashes. Both
supervisors export `CARGO_HOME`/`RUSTUP_HOME` and prepend the toolchain, git
and node directories to `PATH`, because host-mode jobs inherit exactly the
daemon's environment.
| Machine | Supervisor | Manage with |
| -------- | --------------------------------------------- | ------------------------------------------------------ |
| Windows | Task Scheduler task `Gitea Runner (Kigi)` running `C:\Users\zhang\gitea-runner\run-runner.ps1` | `Get-ScheduledTask`, `Start-ScheduledTask`, `Stop-ScheduledTask` |
| macOS | LaunchAgent `com.kigi.gitea-runner` (`KeepAlive`) | `launchctl kickstart -k gui/$(id -u)/com.kigi.gitea-runner` |
`prompt.txt` at the repo root is a one-shot setup prompt for the Mac Mini leg.
Both runners also expose a liveness probe on `http://127.0.0.1:9101/healthz`.
### Gitea-specific things that differ from GitHub
- Workflows live in `.gitea/workflows/`. Once that directory is non-empty,
`.github/workflows/` is ignored completely — you cannot run both.
- The automatic token is `secrets.GITEA_TOKEN`, and the release steps call the
Gitea API directly (`POST /releases`, `POST /releases/{id}/assets`,
`PATCH /releases/{id}`) rather than `softprops/action-gh-release`, which
targets GitHub's API and does not work here.
- `uses:` actions are fetched from `github.com` by default
(`DEFAULT_ACTIONS_URL`), so the runners need outbound access to it — our
GitHub *account* being suspended does not affect downloading public actions.
Absolute URLs (`uses: https://gitea.com/actions/checkout@v4`) work too.
- Artifacts carry only the five checksum lines; the archives themselves go
straight to the release. If `actions/upload-artifact@v3` misbehaves on the
instance, the fallback is to drop the artifact steps and have `publish`
download the archives from the release and hash them there.
> History note: between 2026-08 and 2026-09 this pipeline ran as
> `.gitea/workflows/release.yml` on self-hosted runners against
> `git.zacharyzhang.com` while the GitHub account was unavailable. The Gitea
> instance still hosts the pre-migration releases (`v0.1.12`, `v0.1.13`);
> everything from `v0.1.14` on is built and published here.
## Invariants to keep in lockstep