chore(release): stop publishing to crates.io - #25
Conversation
The release workflow no longer uploads the crate to crates.io, as it is consumed as a git submodule and shipped as module artifacts instead. The `cargo publish` step is removed, though `cargo package` still runs to validate the manifest. The `release-target` job now gates strictly on the tag being created and pushed, rather than on a registry upload that could fail independently and block artifact builds. Auto-committed-on: macbook Co-authored-by: Medulla <medulla@tinyhumans.ai>
Update the release workflow's existing_tag input description to accurately reflect that it skips the version bump and tagging, rather than the crates.io publish, and to use "upload" instead of "publish" for artifact handling. Auto-committed-on: macbook Co-authored-by: Medulla <medulla@tinyhumans.ai>
The crate is consumed as a git submodule rather than from crates.io, so the `publish = false` flag is added to make local `cargo publish` commands fail explicitly instead of silently creating an unused distribution channel. The `documentation` field is also removed since it pointed to docs.rs, which only builds for published crates, leaving the link dead; documentation is now provided via `cargo doc` from the repository. Auto-committed-on: macbook Co-authored-by: Medulla <medulla@tinyhumans.ai>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe crate metadata now disables registry publication and documents local documentation. The release workflow versions, packages, tags, builds, and uploads artifacts without ChangesRelease distribution changes
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This change stops crates.io publication while retaining package validation and artifact release through the existing tagging flow; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant VersionAndTag
participant ReleaseTarget
GitHubActions->>VersionAndTag: Version, package, and push tag
VersionAndTag->>ReleaseTarget: Provide pushed-tag release condition
ReleaseTarget->>GitHubActions: Build and upload release artifacts
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
![tinysweeper[bot]](https://avatars.githubusercontent.com/in/4526585?s=60&v=4){kind=small}
There was a problem hiding this comment.
tinysweeper found nothing blocking. Approving.
$0.0305 · 58,345 in / 17,237 out · 14,848 cached (25%) · deepseek/deepseek-v4-pro-0813, openrouter/openai/text-embedding-3-small · 191 embedded
critique: $0.0141 · 24,013 in / 5,937 out · 3,456 cached (14%) · deepseek/deepseek-v4-pro-0813
security: $0.0097 · 22,848 in / 1,019 out · 2,688 cached (12%) · deepseek/deepseek-v4-pro-0813
description: $0.0027 · 4,478 in / 1,744 out · 1,792 cached (40%) · deepseek/deepseek-v4-pro-0813
tinysweeper
Bot
added
the
priority: p3
1 participant
The problem
Every release has needed two runs: one that tags and fails, then a manual
re-run with
existing_tagto actually build the bundles. That happened onv0.2.3, v0.3.0 and v0.4.0.
The cause is a gate that does not do what its own comment says:
A failed publish does not yield a target — the condition requires success.
So
cargo publishfailing withplease provide a non-empty tokenskippedrelease-target, and with it every artifact job and the GitHub release.The diagnosis was already written down next to it, and it is correct:
Only the fix was missing.
The change
This crate is not published to crates.io — hosts consume it as a git submodule
and get its behaviour as the module artifacts this workflow builds. A registry
upload is a third distribution channel nobody reads. So the step is removed
rather than repaired with a token.
cargo publishstep deleted. NoCARGO_REGISTRY_TOKENanywhere.cargo packagekept, so a manifest that could not be packaged is stillcaught. Nothing uploads it.
publish = falseinCargo.toml, so a localcargo publishrefusesrather than quietly succeeding and creating the channel this removes.
Verified:
error: tinywallet cannot be published.documentation = "https://docs.rs/tinywallet"removed — docs.rs onlybuilds published crates, so that link was dead.
The gate now means what it says. It still needs
always(), but for the onereal reason:
publishis skipped on theexisting_tagrecovery path. It isdeliberately not tolerant of a failure there, because that job now only
versions, packages and tags — and without a tag there is nothing to attach
bundles to. The comment says so.
The job id stays
publishbecause severalneeds:/needs.publish.*references depend on it; its display name is now "Version and tag".
Verification
Next release should be a single run that ends with the GitHub release and its
artifacts.
existing_tagstays as the recovery path for a run that tags andthen fails in the bundle matrix — which is what it was for.
Summary by CodeRabbit
Release Process
Package Metadata