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

Publish from parent workspace #5837

Closed
wants to merge 2 commits into from
Closed

Publish from parent workspace #5837

wants to merge 2 commits into from

Conversation

ufoscout
Copy link

@ufoscout ufoscout commented Jul 31, 2018

This PR deals with #1169

The proposed implementation simply loops all the members of a workspace and publish them in the declared order.
Limitations:

  • cargo publish --dry-run fails if a member has path dependencies; nevertheless, running it without --dry-run will work as expected (because the referred package will be published beforehand)
  • Due the cargo package limitations, it is not possible to upload all the packages together at the end of a global verification, this is because the "path" dependencies need to be present in the repository before the publish process of a package starts.

Please note that these two limitations are not introduced by this PR but are already present in cargo.

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@alexcrichton
Copy link
Member

Thanks for the PR! I'm unfortunately wary of this sort of construction though. There's a lot of reasons I think that you don't want to publish an entire workspace such as when you have internal crates or some are already at the most recent version. This implementation also doesn't do a topological sort to be publishable to crates.io, perhaps publishing the wrong crate first.

This is a really tricky problem, publishing multiple crates. I think an ideal API might look like cargo publish but with -p arguments to accept of packages to publish, and then Cargo automatically publishes path dependencies that also need publication (perhaps with --publish-deps flag or something like that).

That sort of communication and resolution, however, requires communication with the registry about dependency information and such.

@alexcrichton
Copy link
Member

I'm gonna close this for now due to going stale, but we can try to follow up with discussion on the associated issue!

@Charles-Johnson
Copy link

I'm trying to automate my release process with GitLab Actions. I want to publish the crates on my workspace sequentially based on their dependencies but the workflow failed: https://github.com/Charles-Johnson/zia_programming/commit/28b744c4ac556eb222dcf85a09c9160c7be3ef56/checks?check_suite_id=407498492. It looks like after I published the first crate it took a while for it to be available on crates.io and caused publishing the second crate to fail.

I guess I could just sleep for an arbitrary amount in between publishing each crate but I wonder if there is a more robust way of doing this.

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 this pull request may close these issues.

4 participants