search

Byron / cargo-smart-release

Release complex cargo-workspaces automatically with changelog generation, used by `gitoxide`
Apache License 2.0
78 stars 7 forks source link

[smart-release] Add option to skip published crate version checks #3

Closed haata closed 1 year ago

haata commented 1 year ago

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.

Byron commented 1 year ago

Thanks for the suggestion and for explaining where this feature request is coming from. If you wanted to take a stab at it with the proposed solution, I'd welcome a PR.

One thing I wonder about though: Can this problem also be solved by letting smart-release understand that one crate is a binary and the other one is a library? Or better, if cargo has no problem with duplicate names if if both were libraries, can smart-release do the same and adapt automatically?

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

Does this mean that IF the check fails and it would have a version-mismatch, then it would ignore it and not publish only the respective crate?

Assuming that we can align on what the above would mean, one nightmare I see happening is validation as… I have been very spotty with tests on this tool. Complex scenarios can be tested with make journ-tests-smart-release, and I'd strongly encourage you to give that a try when implementing it. That way it's easier for me to validate it, even though it's going to be hard for everybody to assert that nothing else is broken. And the latter happened to me more often than I dare to admit. So I am a bit anxious due to that as well but am willing to fight those fears :).

Thank you

Byron commented 1 year ago

I am closing this as feedback was requested a while ago. If that changes, please feel free to reopen.