Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for releasing all crates in the workspace #53

Closed
mmagician opened this issue Nov 6, 2022 · 6 comments
Closed

Support for releasing all crates in the workspace #53

mmagician opened this issue Nov 6, 2022 · 6 comments

Comments

@mmagician
Copy link
Contributor

For projects with a large number of crates per repository, it would be very useful to have an option to run cargo release from workspace root, so that the version for each crate is bumped consistently across the repo (this also helps with tag management, since we don't want to have a separate tag for each single crate).
Do you think this is something that could be supported by release-pr action? It'd then fit my usecase quite well.

@passcod
Copy link
Member

passcod commented Nov 6, 2022

Sure, we'd need to add a flag to do that, and I'd accept a PR for it.

To help with that, the flag would:

  1. cut into the path/crate resolution to enforce running at the workspace root
  2. change the options of the cargo release command
  3. be added to the template variables so they can switch based on its presence
  4. be added to the default templates to have some reasonable message

@passcod
Copy link
Member

passcod commented Nov 6, 2022

Not related to this but note that this action has no yet been updated to take advantage of the new cargo-release modes for split releases.

@mmagician
Copy link
Contributor Author

Thanks for the pointers! I've started making some changes, but it turns out to be more involved than I initially envisioned.
Some expected behaviour:

  • if a concrete version is specified, then all crates in the workspace should use that version
  • if a release type is specified, then it's simply a bump - version could be different for each crate

Then branch name, PR template and semver checks are all affected.

Let me know whether you'd prefer a full-fledged solution to take care of all the scenarios, or whether you're ok to start off with a limited feature set.
I'm thinking that introducing an option like crate-release-all but only when the concrete version is specified (i.e. all crates will inherit that version) should be an easy win. It definitely would suit my usecase :)

Then we should still decide what to do about semver checks and PR template (maybe skip the checks for multiple crates, and have a slightly adapted PR template for all crates?)

@passcod
Copy link
Member

passcod commented Nov 7, 2022

Yeah, disallowing bump versions when this option is provided is a good start, though there could be some detection that all the versions in the workspace are the same, and so bumping will result in the same output version everywhere (and check that after running cargo-release, too, just in case). But happy with a simple disallow for now. (If there's different versions across the workspace, it should always disallow, and in fact I would go further and fail the entire run if crate-release-all: true and there are different extant versions, as that's probably an invalid/unexpected state that should be fixed manually -- but that's not a strong opinion.)

I think the checks should still run for multiple crates, if possible to do easily.

@mmagician
Copy link
Contributor Author

I think I've got a working action now, I've tested on a fork of cargo-release-pr-test, see the opened PRs here.

@mmagician
Copy link
Contributor Author

Works like a charm for my fork of arkworks-algebra, see example here. There I'm using my own fork of release-pr where I've merged the two open PRs for testing. Once they're accepted and merged upstream, I'd add it to the original algebra repo too!

@passcod passcod closed this as completed Nov 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants