mizchi flaker manual release
Procedure encoded from docs/contributing.md § Releases plus the 0.10.7 and 0.11.1 release sessions. The 0.x line is hand-released — release-please was removed in 0.10.5 (see commit c5da2ea and ADR if asked why).
Pre-flight
git statusclean onmain.git pull --ff-only.- Pick the bump type:
- patch (X.Y.Z → X.Y.Z+1): bug fix, doc update, version-string-only fix
- minor (X.Y.0 → X.Y+1.0): a
feat:commit landed since the last release - major: ASK first; rare in the 0.x line.
- Branch name:
fix/<version>-<slug>(patch) orfeat/<version>-<slug>(minor) per contributing.md. Slug 1-3 words describing the dominant change.
Bump 3 places (one is easy to miss)
| File | Edit |
|---|---|
package.json |
"version": "<new>" |
src/cli/main.ts |
.version("<new>") ← forgotten in 0.11.0, caused a 0.11.1 patch detour. Always grep \.version\( after the bump. |
CHANGELOG.md |
Convert ## Unreleased → ## <version> heading. Match the existing per-version section format (no date suffix in the 0.x line). |
Build / verify
pnpm typecheck # tsc --noEmit
pnpm build # writes dist/cli/main.js + dist/moonbit/flaker.js
pnpm test # vitest run — full suite
All three MUST pass before the PR. If tests/commands/ops-weekly.test.ts fails locally but CI is green, that is/was the date-sensitive flaky-tag-triage now bug fixed in 0.10.7 — not your release.
PR → merge
- One commit:
chore(release): <version>subject. Body summarises CHANGELOG. gh pr create --title "chore(release): <version>" --body ...- Wait for CI:
test,core-tests (with_moonbit_build),core-tests (without_moonbit_build). All must be SUCCESS. gh pr merge <N> --merge --subject "Merge pull request #<N> from ..."(merge-commit style; matches existing main history).git checkout main && git pull --ff-only→ note the merge SHA fromgit log --oneline -3.
Tag + GitHub release + publish
git tag v<version> <merge-sha>
git push origin v<version>
gh release create v<version> \
--title "v<version>" \
--notes "<curated body — typically a tightened version of the CHANGELOG entry>"
publish.yml fires automatically on tag push (OIDC trusted publishing + npm provenance). Wait for it:
gh run list --workflow publish.yml --limit 1 --json status,conclusion
# Or, blocking:
until [ "$(gh run view <run-id> --json status -q .status)" = "completed" ]; do sleep 15; done
gh run view <run-id> --json conclusion -q .conclusion # expect: success
Verify the published version
npm view @mizchi/flaker version # must equal <new>
npx @mizchi/flaker@<version> --version # must equal <new> too — THIS catches the .version() miss
If npx ... --version reports the previous version while npm view version is correct, the src/cli/main.ts bump was missed. Roll forward with a tiny patch release — do NOT retag, npm doesn't allow re-publishing the same version and consumers may have already pulled.
Gotchas
- chaosbringer's
flaker-mergeadvisory check is a pre-existing flake on its side, unrelated to flaker releases. Ignore the FAILURE on that check when merging flaker PRs. gh release createrequires the tag to already be on origin — don't try to create the release before pushing the tag.- Don't skip CHANGELOG — release-please was removed in 0.10.5, so nothing else generates one. Missing entries are user-visible.
What this skill is NOT for
- chaosbringer release (use release-please-driven flow there)
- One-off
npm publishfrom a workstation (the OIDC flow is mandatory; manualnpm publishfrom a laptop will fail without the trusted-publisher token)