[WIP] feat!: bump workspace dependencies with release

[Brooks Townsend (brooksmtownsend)]

Fixes #8

This PR adds support for bumping workspace dependencies just like how the current smart-releaser will bump dependent crates in response to a new release. In order to implement this, I just slotted some logic in with the existing logic to find dependent crates to also look for a workspace.dependencies section in the Cargo.toml.

This works... mostly. It actually works perfectly for dependencies that the main workspace uses, but it does not work when a dependency is specified at the workspace level but not used by the main workspace.

For example, I was taking a look at this for wasmCloud. If I use this to bump the crate wasmcloud-core, which our primary package depends on, I get the expected result (wasmcloud-core bumps from 0.5 to 0.6, workspace dependency updates. However, if I use this to bump wash-lib, this is specified as a workspace dependency but wasmCloud itself doesn't use it, so no update. I wanted to open up this PR as a draft WIP while I work through this just to let you know I'm working on it 😄

Some trace logs from a run (will remove extraneous trace logs when I mark this as ready of course):

[TRACE] Updating wasmcloud
[TRACE] Crates that may change wasmcloud-core, opentelemetry-nats, provider-archive, wasmcloud-runtime, wasmcloud-tracing, wasmcloud-host, wasmcloud-provider-sdk, wasmcloud-provider-blobstor
e-fs, wasmcloud-provider-blobstore-s3, wasmcloud-provider-http-client, wasmcloud-provider-http-server, wasmcloud-provider-keyvalue-redis, wasmcloud-provider-keyvalue-vault, wasmcloud-provide
r-lattice-controller, wasmcloud-provider-messaging-kafka, wasmcloud-provider-messaging-nats, wasmcloud, wash-cli, wash-lib
[TRACE] Found workspace dependencies
[TRACE] Pending 'wasmcloud' manifest workspace-dependencies update: 'wasmcloud-core = "^0.6.0"' (from  "0.5")
[TRACE] Pending 'wasmcloud' conservative manifest workspace-dependencies update: 'provider-archive = "^0.10.1"' (from  "0.10")
[TRACE] Pending 'wasmcloud' manifest workspace-dependencies update: 'wasmcloud-tracing = "^0.4.0"' (from  "0.3")
[TRACE] Pending 'wasmcloud' manifest workspace-dependencies update: 'wasmcloud-provider-sdk = "^0.5.0"' (from  "0.4")

[Brooks Townsend (brooksmtownsend)]

I think test is failing because I added extra output.

Thinking out loud, I think I need to consider a workspace root as something that may always change in response to a version bump, and that'll work well to catch my edge case

[Sebastian Thiel (Byron)]

Thanks a lot for getting the ball rolling on workspace dependency support!

I thought that maybe it's worth it to try to create a new journey tests that exercises this new capability as well.

The biggest issue I see with any change is that it might very well break gitoxide and I'd only know when it's too late. So I suppose I could use this PR for a while and if it works for both of us, it can be merged 😅.

[Brooks Townsend (brooksmtownsend)]

Sebastian Thiel (@Byron) what kind of tests could we add to add confidence in not breaking gitoxide? I'd be happy to guinea pig test this release, though I can only speak to a few use cases 😕

edit: I totally missed that gitoxide is a user of this binary, so that makes sense that we don't want to break it 😄

[Sebastian Thiel (Byron)]

I don't think given this requirement, there isn't anything less but to publish gitoxide itself, and such a publish can come in many different shapes. Impossible to model these. On the bright side, that's the only requirement, so if I manage to create one release with a version from this PR, I'd assume it's not breaking anything.

But like a said, a simple Journey test should probably be added to generally show how it works with workspace dependencies.

[Brooks Townsend (brooksmtownsend)]

Just a note my latest commit isn't quite ready for code review, but it does work! There's some edge cases I have called out in the TODO, and more to test, but I'm planning on trying it out to release a few crates this week (likely via manual inspection)

[Sebastian Thiel (Byron)]

By the way, I tried to publish with this branch but it failed with an issue around invalid manifests being written. cargo metadata failed due to that. I am sorry to not have the specific output, I forgot to save it while it was still available in the terminals history.

[Brooks Townsend (brooksmtownsend)]

Thank you for letting me know Sebastian Thiel (@Byron) , I think an issue here (with my implementation) is still that

• smart-release with workspace dependencies still edits manifest without --execute

If that wasn't the issue though, let me know what the error is and I can try to track it down 🙂

[Sebastian Thiel (Byron)]

Thank you! I think it should be possible to reproduce the issue if the gitoxide main branch is reset to 9511416a6cd0c571233f958c165329c8705c2498. Then, cargo smart-release will do strange things, I think it does indeed change a manifest (maybe too early), but in a way that fails cargo metadata invocations.

[Brooks Townsend (brooksmtownsend)]

Yeah I bet if you have any pre-check step then the above bug will cause an issue, e.g. run without --execute to double check, then run with --execute