search

pksunkara / cargo-workspaces

A tool for managing cargo workspaces and their crates, inspired by lerna
MIT License
472 stars 46 forks source link

Add --dry-run option #4

Open CAD97 opened 4 years ago

CAD97 commented 4 years ago

This would be useful for learning how the tool works without accidentally changing remote state. Go through all of the motions of the command, but revert any and all changes and print a list of what actions were taken.

pksunkara commented 4 years ago

I agree, unfortunately, it was a bit complex for me to add it as part of the first release.

pksunkara commented 3 years ago

The hard part here is git related actions.

mathstuf commented 3 years ago

I think just reporting "would run git …; further action may depend on its results" is sufficient there as a first pass.

leighmcculloch commented 2 years ago

Another issue is what to do with crates in the workspace that are dependent on each other. It is not possible to use the official cargo publish --dry-run command on a crate if that crate is dependent on another crate version that isn't yet published.

leighmcculloch commented 2 years ago

I experimented with adding dry run support to cargo workspaces, and I think I came up with this workflow that works, although it doesn't address that last issue I mentioned above. The change is here: https://github.com/pksunkara/cargo-workspaces/pull/78.

@pksunkara In terms of git related actions, I made the dry run option disable git pushes. I left the other git operations enabled because it is somewhat blurry where the 'dry run' line should fall on what happens and what doesn't. It is useful for the commit and tag to be created so as to see what would have resulted during a dry run, but it could also be annoying that this happens. However, because those things have their own options it is always possible for someone to turn them off.

leighmcculloch commented 2 years ago

Note that change #78 doesn't support workspaces where crates are dependent on each other, since cargo publish requires all dependencies to have been published even during a dry run. I didn't see a way to address this at this time.

I think the only way might be to have cargo-workspaces embed a local registry and run a http server for it and have cargo publish to that local registry as a "dry run". This could potentially be an extension made after #78.

pksunkara commented 3 months ago

Implemented dry run option for publishing as part of #154. Still need to figure out how to do it for versioning correctly.