Two related fixes uncovered while recovering the v0.5.0 publish.
1. crates.io API requires a User-Agent header. The `publish_if_new`
skip check was doing a bare `curl -fsSL https://crates.io/api/...`
which crates.io rejects with HTTP 403. With `-f` curl exits
non-zero, the pipeline returns empty, the script doesn't recognize
already-published crates, and we fall through to a real publish
attempt. On a re-run that means cargo publish errors with
"already exists on crates.io index" for crates that DID publish
successfully on the previous run.
Fix: send a `User-Agent: ModernRelay-omnigraph-ci (URL)` header.
2. Defense in depth: even with the UA, the API could hiccup. If the
skip check misses an existing version and cargo publish errors
with "already exists on crates.io index", treat as success
instead of failing the whole run. This makes the workflow
re-runnable after any partial publish without needing manual
intervention.
Both fixes are required to recover from the v0.5.0 partial publish
where omnigraph-compiler@0.5.0 made it through but the run failed
before omnigraph-policy / engine / server / cli — re-triggering the
workflow now succeeds end-to-end.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
omnigraph-policy is a new crate this release cycle (Cedar policy
engine, MR-722). It wasn't added to the publish list when it was
created, so v0.5.0's tag-triggered publish run succeeded for
omnigraph-compiler but failed at omnigraph-engine:
failed to prepare local package for uploading
Caused by:
no matching package named `omnigraph-policy` found
location searched: crates.io index
required by package `omnigraph-engine v0.5.0`
omnigraph-policy has no internal omnigraph-* deps so it can publish
after omnigraph-compiler (either could go first). omnigraph-engine
depends on both; server on the three; cli on everything.
publish_if_new is idempotent — re-running with the v0.5.0 tag after
this lands will skip omnigraph-compiler (already published), then
publish policy + engine + server + cli.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The release.yml workflow builds binaries and updates Homebrew but never
published to crates.io — v0.4.0 and v0.4.1 are missing from the registry
even though the local Cargo.toml and the v0.4.1 tag are at 0.4.1.
This adds a separate workflow that:
- auto-publishes on every v* tag push (future releases self-publish)
- can be manually dispatched with a tag input (catch up on v0.4.1)
- is idempotent: skips a crate if its current crates.io version already
matches local, so a partial failure is safe to retry
- gates on CARGO_REGISTRY_TOKEN (already in repo secrets); skips cleanly
if the token is ever rotated out
Publishes in dependency order: omnigraph-compiler → omnigraph-engine →
omnigraph-server → omnigraph-cli. Path-only deps in Cargo.toml carry
explicit version fields, so cargo publish strips paths and resolves
against crates.io.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
