Add CI job to publish on crates.io when a release is tagged #713
Conversation
|
We've used such a thing in e.g. glutin/winit and I'd say that it's very tricky. Especially when your crates depend on each self, etc. It's also very easy to mess things up. Though, I don't object the changes. |
Huh. That worked testing on my fork... Some things might be different when running on a PR from a fork, but that particular message doesn't make much sense. |
Hopefully the checks done by something like https://github.com/crate-ci/cargo-release also seems worth looking at, though it seems it still has some limitations. I haven't figured out exactly how that works. |
|
LGTM overall, thanks a lot for taking the time to setup that! Regarding the crates that are missing an owner, I'll take care of that before we merge this. Regarding the CI failure, given the error messages mention reading |
The `katyo/publish-crates` action requires that all crates in a repository depend on the latest version of any other crate in the repo. This seems reasonable, and is probably a best practice.
This uses `katyo/publish-crates@v1`, which checks which crates have had their versions bumped, and releases them on crates.io. While making sure to publish dependencies first before the crate that depends on them. This has apparently worked well in drm-rs. Since subcrates are versioned differently, when we discussed this earlier date-based tags names seemed best. So as @elinorbgr suggested, this goes with `release-YYYY-MM-DD` as the tagging scheme. (The CI job checks for tags prefixed with `release-`). I can't really think of anything better than that. So to release, we should be able to simply update the versions in `Cargo.toml` files, update the changelog files, and tag a release. The `publish-crates` action requires that all subcrates depends on the latest version of any other crate in the repository. And it requires that all crates with changes have a bumped version so they can be released. This seems a bit annoying if we wanted to just release a change to `wayland-backend`, for instance, but should help avoid mistakes. Manually dealing with the releases for all the crates here, without any automated checks, is error-prone. The action here does a `dry-run` for all CI runs (and uses `ignore-unpublished-changes` to not error if crates have changes without already having their versions bumped). But disables `dry-run` when a tag is pushed with the right format. A `CRATES_TOKEN` secret will need to be added to the repository for this to work.
|
Okay, it's not failing now, after changing So hopefully this will work. The CI log lists some errors, but doesn't fail: So to release, we'd want to bump all the crates it complains about, make sure it prints no other messages, then tag a release. |
|
Okay, I understand how So as an alternative to this CI job, a command like
So that actually automates more of the process than |
This uses
katyo/publish-crates@v1, which checks which crates have had their versions bumped, and releases them on crates.io. While making sure to publish dependencies first before the crate that depends on them. This has apparently worked well in drm-rs.Since subcrates are versioned differently, when we discussed this earlier date-based tags names seemed best. So as @elinorbgr suggested, this goes with
release-YYYY-MM-DDas the tagging scheme. (The CI job checks for tags prefixed withrelease-). I can't really think of anything better than that.So to release, we should be able to simply update the versions in
Cargo.tomlfiles, update the changelog files, and tag a release.The
publish-cratesaction requires that all subcrates depends on the latest version of any other crate in the repository. And it requires that all crates with changes have a bumped version so they can be released. This seems a bit annoying if we wanted to just release a change towayland-backend, for instance, but should help avoid mistakes. Manually dealing with the releases for all the crates here, without any automated checks, is error-prone.The action here does a
dry-runfor all CI runs (and usesignore-unpublished-changesto not error if crates have changes without already having their versions bumped). But disablesdry-runwhen a tag is pushed with the right format.A
CRATES_TOKENsecret will need to be added to the repository for this to work. I am not currently a member of smithay/publishers on crates.io, andwayland-backendandwayland-protocols-*don't currently havesmithay/publishersas an owner, so @elinorbgr will have to add that. (And make suresmithay/publishersis an owner of all the crates is probably a good idea.)