Release model
Releases are repo automation, not manual steps: scripts/release.sh is triggered by bupha watch on each main push — a debounce window (default 5 min, MYCO_RELEASE_DEBOUNCE) means only the last push in a quiet window actually releases. The script runs inside a detached worktree and pushes commits and tags from there, never from the main checkout.
What a release run does
- Diff since the last tag — crates under
crates/that changed sincegit describe --tagsare the release set; themycobinary re-publishes whenever any crate changed. No crate changes, no release. - Per-crate patch bump + publish —
cargo set-version -p <crate> --bump patch, thencargo publishwith retries. Each crate gets its own tag<crate>-v<ver>— versions diverge independently in the monorepo. - Commit + push — one
release: bump crate versionscommit, pushed tomainwith the tags. - Binary dist — when
distandghare available, a localdist buildproduces the shell installer (dist-workspace.toml, host archx86_64-unknown-linux-gnuonly — other targets are a TODO for remote workers), uploaded to a GitHub Releasemyco-v<ver>with generated notes.
With no tags at all the script exits early — the flow is seeded by tagging once.
Constraints
- The crates.io name
mycois currently held by an unrelated project, socargo publishof the CLI package depends on resolving that; installs should usecargo install --git https://github.com/9aia/mycoregardless. - Library crates publish normally under their
myco-*names.
CI and docs deploys
The same bupha watch owns the rest of what used to be GitHub Actions — there are no workflows in the repo:
- Push to
docsrunsscripts/deploy-docs.sh, which rebuilds the site and pushesgh-pages— Pages is a legacy branch deploy, so that push is the whole release of the site. - Push to
mainis gated locally by thepre-pushhook (cargo xtask check).scripts/ci.sh(check && test) is ready for bupha, but the watcher routes onebranchper repo name today — a second9aia/mycoentry needs bupha's[[repo.jobs]]work (its T-004).