Allow publishing to crates with a publish = ["custom-registry"] set
#19
Conversation
|
First test and this is already breaking, because EDIT: I'm not exactly seeing what currently makes |
|
Thanks for contributing.
It uses |
|
Somehow it seems to figure it out. As edited above, I think it's because of making changes to crates that cause it to republish (as expected, but it was a bit annoying for my test-case). |
|
The problem is that it won't be able to assure that the proposed crate version is more recent than the latest published one, and thus fail publishing. |
… show up in the index
…`crate_index::Error::Git`'s `#[from]`
It doesn't fail, as pointed out above it seems to be looking at the git tags to understand whether the crate has already been published. This seems much less consistent/ideal than:
The problem is more obvious in a different way though. Digging further with actually reading from my custom registry, it looks like |
|
Sounds like a can of worms. The version-tags are important for knowing the segments of commits which should contribute to the changelogs by the way. |
Fixes #18
Draft because this requires some testing, and figuring out how
cargo publishbehaves in various combinations, and howsmart-releaseshould follow:publish = ["one", "two"]contains multiple registries?--registry foocombines withpublish = ["bar"], that crate is skipped;--registry foocombines with unsetpublish, the crate is published tofoo;publish = ["foo"]is set without--registryCLI argument, the crate is automatically published tofoo(orcrates-ioispublishis unset).EDIT: Sorry for this really quick&dirty change, don't want it to be forgotten about but it's on a tangent of a tangent for me :)