-
Notifications
You must be signed in to change notification settings - Fork 507
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
[CI] Convert crate publish readiness checks to Rust #2590
Comments
So, to be clear, this issue is only proposing to translate the functionality that currently exists in |
I suppose this is a little open ended, as long as it improves the overall reliability of the automated release process. However, the minimum is to cover the example cases I mentioned, which the scripts currently addresses during CI. These scripts are admittedly naive, so I'm open to solutions that aren't exact ports, as long as there's justification. If you have other ideas, I'm open to hearing you out. Ideally, no one should need to think too hard about resolving these issues if they arise. I think this will be addressed by giving clear feedback to contributors. |
From what I can tell, |
**Notable changes** + Does not download `https://static.crates.io/db-dump.tar.gz` to check if crates are published (very slow) + Instead requests `https://crates.io/api/v1/crates/{crate_name}/versions` - 404 indicates that the crate is not published **TODO** + [x] Test source diffing + [x] Display source changes + [x] Test manifest diffing + [x] Decide whether deleted manifest keys should be ignored or flagged + [x] Display manifest changes + [x] Download crates without an external tool (currently using `cargo-download`) + [ ] ~~Diff source without an external tool (currently using `diff`) - maybe? Might not be worth the effort.~~ + [x] Add a `--verbose` mode + [x] Download crates concurrently + [x] Colorize diff Related: #2590
Stale issue message |
These tests together are pretty useful for ensuring release doesn't surprise use with crate version number related noise, but doesn't give enough feedback for new or external contributors.
For context, my ideal solution is to use something like https://github.com/obi1kenobi/cargo-semver-check, since it provides feedback about what kind of version bump to perform.
After a (very) quick check, I did not find a single tool that handles the edge cases that we look for before during publishing.
Examples of changes
This conversion will help close the gap for the ability to contribute to a community-supported crate that will handle our edge cases.
The text was updated successfully, but these errors were encountered: