ci(harness-bundle): publish every bundled dep at the harness version - #121
Conversation
The bundle workflow used to publish each in-repo dep at whatever was in its local Cargo.toml. That left the registry with mismatched versions (harness 0.1.2 + deps 0.1.1) and produced HTTP 409 duplicates every time harness was re-released without bumping deps. Now every dep in the publish set ships at the harness tag's version. _rust-binary.yml gains a version_override input that rewrites [package].version in the dep's Cargo.toml before cargo build, so the binary's CARGO_PKG_VERSION matches the version we publish at. Also fixes the registry-lookup endpoint (/workers/<name> returned 404 for everything; the right one is /download/<name>), so the "skip if already registered at >= harness version" check can actually fire. Excluded from the bundle as before: shell, skills, iii-sandbox.
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughThe PR introduces version override capability to the Rust binary workflow and updates the bundle release workflow to coordinate all bundled dependency versions with the harness tag version. The base workflow now accepts ChangesBundle Release Version Coordination
Sequence DiagramsequenceDiagram
participant ReleaseWorkflow as release-harness-bundle
participant RegistryAPI as Registry API
participant BaseWorkflow as _rust-binary workflow
participant Manifest as Manifest File
ReleaseWorkflow->>RegistryAPI: GET /download/{worker}
alt HTTP 204 (engine-baked)
RegistryAPI-->>ReleaseWorkflow: no metadata
else HTTP 200
RegistryAPI-->>ReleaseWorkflow: current version
end
ReleaseWorkflow->>ReleaseWorkflow: Compare harness_version vs registry version
alt harness_version > registry version
ReleaseWorkflow->>BaseWorkflow: Call with version_override=harness_version
BaseWorkflow->>Manifest: Read manifest at manifest_path
BaseWorkflow->>Manifest: Rewrite [package].version field
BaseWorkflow->>BaseWorkflow: Build binary with new version
else Skip
ReleaseWorkflow->>ReleaseWorkflow: Queue skip (version too old)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
skill-check — worker6 verified, 20 skipped (no docs/). 82 errors across the verified workers.
|
Summary
release-harness-bundle.yml: every in-repo dep inharness/iii.worker.yamlships at the harness tag's version instead of its localCargo.tomlversion._rust-binary.yml: new optionalversion_overrideinput rewrites[package].versionin the manifest beforecargo build, so the published binary embeds the coordinated version./workers/<name>→/download/<name>) so the "skip if already registered" check actually works instead of always falling through.Why
Today, tagging
harness/v0.1.2publishes harness@0.1.2 but every dep stays at whatever's in its ownCargo.toml— typically 0.1.1 from the last bump. The registry rejects re-publishing 0.1.1 with HTTP 409 (Version 0.1.0 already exists for hook-fanout, same for llm-budget last run), and the version landscape becomes confusing: harness 0.1.2 ships with deps that say 0.1.1.After this PR, tagging
harness/v0.1.3produces a coherent bundle: harness 0.1.3 + every bundled dep 0.1.3. No manual per-dep bumps required, no spurious 409s.Cargo.toml in repo can lag
Per the design choice — the workflow rewrites
[package].versionon the fly in the build job. The repo'sCargo.tomlfiles don't need pre-release bumps. The tradeoff:cargo buildlocally still reports the dev version (e.g., 0.1.1), only the published artifact reports the harness version.Excluded from the bundle
shell— releases on its ownshell/v*tag viarelease.ymlskills— held by maintainers, separate tagiii-sandbox— external engine workerTest plan
harness/v0.1.3post-merge → confirm harness + 11 deps publish at 0.1.3, no HTTP 409sreleases/download/<dep>/v0.1.3/<dep>-<target>.tar.gzcontains a binary whose--manifestJSON reportsversion: 0.1.3Summary by CodeRabbit