- .github/workflows/release.yml: on tag v* build all 5 targets (macOS
arm64/x86_64, Linux arm64/x86_64 incl. free arm runners, Windows
x86_64) with the release-dist profile, archive kigi-<version>-<triple>
with LICENSE/NOTICE/THIRD-PARTY-NOTICES, generate SHA256SUMS, publish
the release (prerelease for tags containing '-'), with a tag↔workspace
version guard.
- install.sh / install.ps1 (repo root): platform detection, latest or
--version download from GitHub Releases, SHA-256 verification against
SHA256SUMS, install into the kigi home's downloads/ + bin/kigi symlink
(the same layout the self-updater manages), smoke test, PATH guidance.
- kigi-update rewritten onto the GitHub Releases API (documented wire
shape; stable=/latest, alpha=semver-max across the list, pinned=/tags):
SHA-256 gate before any binary swap, tar.gz/zip extraction per
platform, atomic bin/kigi symlink swap, channel/rollback semantics and
the KIGI_AUTO_UPDATE gate preserved verbatim; every x.ai/GCS/npm
endpoint deleted, npm/gh-release installers removed, legacy grok/agent
links retired on install. kigi-env owns the update base URL with a
KIGI_UPDATE_BASE_URL override (this is what the test artifact server
injects).
- .cargo/config.toml: removed the non-portable neoverse-v2 CPU pin on
Linux arm64 (fleet-specific); RELRO/NX hardening link-args now apply
to the gnu targets too, matching the release-dist profile's contract.
- THIRD-PARTY-NOTICES regenerated via cargo-about (about.toml +
template); the M0 hand-built file is dropped and README points at the
generated one. docs/RELEASE.md carries the release checklist.
- Deleted xAI-era leftovers: kigi-tui/scripts/install*.{sh,ps1} (x.ai
CDN) and the @xai-official/grok npm skeleton (PRD F8: no npm).
Gates: fmt clean; workspace check/clippy 0/0 (--locked, -D warnings);
kigi-update 58 lib + 86 integration tests green; deny ok;
release-dist build of kigi-bin succeeds and reports 'kigi 0.1.0'.
2.3 KiB
Release checklist (PRD F8)
Kigi ships as a single-file binary for five targets, published on this
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.
Cutting a release
-
Bump
[workspace.package] versioninCargo.toml; land the change onmainwith green CI. -
Regenerate the third-party notices (not enforced by CI — this is the step that keeps
THIRD-PARTY-NOTICES.mdfresh):cargo install cargo-about --locked # once cargo about generate about.hbs -o THIRD-PARTY-NOTICES.mdCommit the result if it changed.
-
Tag and push:
git tag vX.Y.Z && git push origin vX.Y.ZThe tag must equal the workspace version (
vX.Y.Z↔X.Y.Z); the workflow fails fast on a mismatch. -
The
Releaseworkflow builds all five targets with the hardenedrelease-distprofile, packageskigi-<version>-<target-triple>.{tar.gz|zip}archives (binary + LICENSE + NOTICE + THIRD-PARTY-NOTICES), generatesSHA256SUMS, and publishes the GitHub Release. Tags containing-(e.g.v0.2.0-alpha.1) publish as pre-releases, which only thealphaupdate channel picks up. -
Smoke-test an installed artifact:
curl -fsSL https://raw.githubusercontent.com/ZacharyZhang-NY/Kigi-CLI/main/install.sh | sh ~/.kigi/bin/kigi --version
Invariants to keep in lockstep
- Asset naming
kigi-<version>-<target-triple>.{tar.gz|zip}and theSHA256SUMSmanifest are consumed by three clients:install.sh,install.ps1, andauto_update::release_asset_name()incrates/codegen/kigi-update. Change one, change all (the kigi-update testtest_release_asset_name_matches_release_workflow_namingpins the Rust side). - Never publish two builds of the same semver version differing only in
build metadata (
+…) — thesemvercrate orders build metadata, so auto-update would bounce users between them. - Rollbacks: deleting the bad release (or re-pointing "latest") is enough — the internal installer treats the Releases API as authoritative and downgrades clients on its own.
- No PyPI/npm packages, ever; in particular never squat the
kimi-clipackage name (PRD F8).