[mrcrgl]

Context

A change of the API should reach a released SDK, and the MCP tools and CLI built on it, without anyone's hands. Today the regeneration pull request waits for a person to merge it, and a release is published to crates.io by hand. The crates aren't published yet.

Approach

• Version. regenerate.yml sets the next version in its pull request with scripts/version.sh bump. That is the version of every crate and of the origincloud-core each service crate depends on, followed by cargo update --workspace. It is a minor version when API_REVISION moved, a patch for a change of the generator alone. A pending bump that isn't released yet stays; a minor one replaces a pending patch. The crates keep their own versions rather than a workspace version, because the generator's scaffolding of a new crate copies the core crate's manifest.
• Merge. merge-regeneration.yml runs when CI completes on the regenerate branch. It merges when CI passed on the head commit and every commit is the regeneration workflow's, unless the pull request adds a crate. A new crate's description and keywords need review, and its first version needs publishing by hand, so that pull request gets a comment and waits.
• Release. release.yml runs when CI passes on a push to main. If the version has no tag yet, and is newer than every tag, it publishes it to crates.io with trusted publishing from the environment release.
  • The core crate goes first, then the service crates.
  • It skips a crate whose version is published already, so a release that failed half way finishes when it runs again.
  • A crate that isn't on crates.io yet fails the release with its name, because trusted publishing reaches only existing crates.
  • Then it tags the commit and dispatches origincloudhq/mcp's regeneration.
• Credential. The regeneration's push, the merge and the dispatch use a GitHub App's token (variable REGENERATE_APP_ID, secret REGENERATE_APP_PRIVATE_KEY). Without the App, the regeneration works as before, dispatching CI itself, and the merge stays by hand.
• RELEASING.md describes the automatic path, a new crate's first publish, and the manual path.

Before it can release

The first publish of origincloud-core, origincloud-pvs and origincloud-location is by hand, and each crate needs this repository as its trusted publisher (release.yml, environment release). Until then, a merge to main makes the release fail, naming the crates.

Trade-offs / risks

A bot-only regeneration merges and releases with no review in this repository. It holds only what the generator makes from a reviewed API change, and CI, including cargo package, checks it.

How to test

scripts/version.test.sh   # the version rules, against a throwaway repository with tags
shellcheck scripts/*.sh