Summary 💡

Add cli option to remove any checking/verification against crates.io

e.g.

--no-published-crate-verification
   Do not verify version against published crates. Also implies --no-publish as this
   crate likely should not be published.

I'm happy to take a stab at this as a PR if you think it's not too difficult.

Motivation 🔦

I'm using smart-release in a bit of an unusual way (excellent tool btw!). Basically, I'm using it to create tags in GitHub for various releases and ignore crates entirely. In my case my cargo targets are embedded binaries which will never be published to crates.io (the build also use cargo-make and selective linkers and compiler targets which makes typical cargo publish tests difficult anyways).

Unfortunately in my case, there's a duplicate name of one of the packages and I get an error.

cargo smart-release -u keystonetkl keystonefs kira gemini --no-publish  --no-isolate-dependencies-from-breaking-changes
[INFO ] Updating crates-io index
[WARN ] Crate 'kira' computed version not greater than the current package version. Updating crates index to assure correct results.
[WARN ] Refused to publish 'keystonetkl' as as it didn't change.
[WARN ] Refused to publish 'keystonefs' as as it didn't change.
[WARN ] Refused to publish 'gemini' as as it didn't change.
[INFO ] Will not publish or alter 4 dependent crates: unchanged = 'kiibohd-atsam4s', 'keystonetkl', 'keystonefs', 'gemini'
[ERROR] Latest published version of 'kira' is 0.7.1, the new version is 0.1.1. Consider using --bump <level> or update the index with --update-crates-index.
[INFO ] WOULD auto-bump provided package 'kira' from 0.1.0 to 0.1.1 for publishing, 0.7.1 on crates.io
Error: Aborting due to previous error(s)

I can obviously just rename kira to something else, but since I can't easily reserve the names (and really I shouldn't name-squat something I'm not going to be using anyways...) it would be nice to just remove this check entirely.

Currently one has two options:

• use --auto-publish-of-stable-crates to safety-bump stable crates just like unstable ones, causing unnecessary churn downstream
• not do the above and see the publish fail as the manifest wasn't updated with new/bumped versions of workspace dependencies.

What would be required is the give them a patch-level bump instead, while keeping everything else as is (maybe even by default). That way they could be published as usual and everything should work fine.

First off, this crate is awesome. It is so close to being a does-what-you-want publish tool for cargo crates.

For this project though, we set our version numbers in the root workspace and cargo-smart-release doesn't seem to update things there. When the publish step comes, cargo fails because versions don't match.

If organizing workspaces like this is bad practice, I can change it. That's one major problem with large Rust projects and workspaces. There is no "do it this way" guide that actually works from start to publish.

I tried to reorganize the project to align with git-oxide. I moved the binary to the root and combined the package & workspace Cargo.toml, but it wasn't enough.

If this seems like a bug in cargo-smart-release vs how we structured our project, I'll gladly submit a PR if you can guide me to the part of the codebase I should start in.

Thanks again!

Current behavior 😯

❯ RUST_BACKTRACE=1 cargo smart-release
[WARN ] Consider running with --update-crates-index to assure bumping on demand uses the latest information
[WARN ] Using 'brix' as crate name as no one was provided. Specify one if this isn't correct
thread 'main' panicked at 'path must exist in current commit', /home/xeno/.asdf/installs/rust/1.71.1/registry/src/index.crates.io-6f17d22bba15001f/cargo-smart-release-0.20.0/src/git/mod.rs:50:26
stack backtrace:
   0: rust_begin_unwind
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/panicking.rs:67:14
   2: core::panicking::panic_display
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/panicking.rs:150:5
   3: core::panicking::panic_str
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/panicking.rs:134:5
   4: core::option::expect_failed
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/option.rs:1932:5
   5: cargo_smart_release::git::change_since_last_release
   6: cargo_smart_release::traverse::dependencies
   7: cargo_smart_release::command::release_impl::release_depth_first
   8: cargo_smart_release::command::release_impl::release
   9: cargo_smart_release::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Expected behavior 🤔

I'm not sure; this is my first attempt to use it. I would expect more helpful messaging; at the very least. a stack trace feels weird.

Steps to reproduce 🕹

this repo/sha should reproduce

https://github.com/xenoterracide/brix/commit/178ece2401ab64bd1d014311bf6824618fd94db5

Summary 💡

Create a mode of cargo-smart-release that is aware of special commits with type "release". The idea being that release commits are where changelogs and versions are automatically updated, and the commit description identifies which of the crates are being released. This has the benefit that a. it provides a way to signal to CI which things need to be released (by reading the commit description), b. the tool can know that it is only traversing back to the last release commit, c. and because it doesn't go past the release commit they act as a safe place to rename/relocate crates.

What do you think about adding this flow to cargo smart-release?

Motivation 🔦

I'm working on developing a release process for wit-bindgen, a Bytecode Alliance project, which has multiple crates that I would like to version more separately using something like cargo smart release. The features I'm asking for would help us implement the proposed process without requiring a ton of maintainer work.

See this comment for details: https://github.com/rust-lang/cargo/pull/9478#issuecomment-1153392615.

If it becomes a cargo issue we can track it here.

In the mean time, one can delete the generated files in question .

Tasks

• [ ] make the issue reproducible and file an issue, PR (see this comment for more information
• [ ] maybe even provide a fix