Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add CI job to publish on crates.io when a release is tagged
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.
- Loading branch information