-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
chore: Automatically update dependencies monthly #12341
Conversation
This will update `Cargo.toml` and `Cargo.lock` at the same time. By default, all dependencies will be updated, so we pull out the compatible dependencies into a consolidated PR. This starts off with the dependency dashboard and automerging being disabled but explicitly specified to call attention to the potential for this. We can evaluate these later.
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not quite what I would use, but this looks good for achieving your goals! :)
Thanks for this! I was thinking about the same thing early today. rust-lang/rust did a similar thing from another angle: |
RenovateBot will provide us a bit better of an experience with giving us release notes. Also a potential future change is for the semver-check job to be run using the latest version of rust with a CI job to update that version (thanks to RenovateBot). This would isolate error change failures to a PR rather than affecting all PRs. |
6bb152b
to
12622ab
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just looked into their docs. The current one configuration looks great to me. I don't think we can enable automerge as it may bypass bors or be blocked by bors.
It seems like every 6 weeks
works. I just don't know how to configure the start date.
> later.schedule(later.parse.text('every 6 weeks')).next(10)
[
2023-07-31T00:00:00.000Z,
2023-09-11T00:00:00.000Z,
2023-10-23T00:00:00.000Z,
2023-12-04T00:00:00.000Z,
2024-01-01T00:00:00.000Z,
2024-02-12T00:00:00.000Z,
2024-03-25T00:00:00.000Z,
2024-05-06T00:00:00.000Z,
2024-06-17T00:00:00.000Z,
2024-07-29T00:00:00.000Z
]
I think a more frequent update is fine (bi-weekly?). I can check in that.
Going to merge it now. If someone objects to this or it ends up too noisy, we can always disable it afterward. @bors r+ |
☀️ Test successful - checks-actions |
Have we confirmed whether or not the renovatebot app is installed for all rust-lang repos, or just select ones? |
Got an impression from @Turbo87 that we need to inform infra team to enable that. |
refactor: Clean up package metadata ### What does this PR try to resolve? Clean up workspace metadata - Reduce noise by allowing fields to be inferred - I left documentation because that is runtime inferred on crates.io which has trade offs - Default package fields at the workspace level Align us on a single edition ### How should we test and review this PR? Mostly relying on CI for this ### Additional information I noticed this and decided to do this while I was considering the idea of setting an MSRV to "latest" by leveraging #12341 and whether that should just be for `cargo` or for all workspace members. I'm leaning towards all workspace members as that is the only thing we test though strictly speaking people might be able to use lower versions; we just wouldn't officially support it.
refactor: Clean up package metadata ### What does this PR try to resolve? Clean up workspace metadata - Reduce noise by allowing fields to be inferred - I left documentation because that is runtime inferred on crates.io which has trade offs - Default package fields at the workspace level Align us on a single edition ### How should we test and review this PR? Mostly relying on CI for this ### Additional information I noticed this and decided to do this while I was considering the idea of setting an MSRV to "latest" by leveraging #12341 and whether that should just be for `cargo` or for all workspace members. I'm leaning towards all workspace members as that is the only thing we test though strictly speaking people might be able to use lower versions; we just wouldn't officially support it.
Update cargo 11 commits in 694a579566a9a1482b20aff8a68f0e4edd99bd28..1b15556767f4b78a64e868eedf4073c423f02b93 2023-07-11 22:28:29 +0000 to 2023-07-18 14:44:47 +0000 - Fix "cargo doc --open" crash on WSL2 (rust-lang/cargo#12373) - fix(git): respect scp-like URL for nested submodules (rust-lang/cargo#12359) - Upgrade to indexmap v2 (rust-lang/cargo#12368) - refactor: Clean up package metadata (rust-lang/cargo#12352) - Correct unspecifiead to unspecified (rust-lang/cargo#12363) - Replace invalid `panic_unwind` std feature with `panic-unwind` (rust-lang/cargo#12364) - Bump to 0.74.0; update changelog (rust-lang/cargo#12361) - Bump version of crates-io due to unintentional semver-breaking change (rust-lang/cargo#12357) - chore: Automatically update dependencies monthly (rust-lang/cargo#12341) - docs: Use heading attributes to control the fragment. (rust-lang/cargo#12339) - Rustfmt with latest nightly. (rust-lang/cargo#12351) r? ghost
What does this PR try to resolve?
This will create PRs that will update
Cargo.toml
andCargo.lock
at the same time. By default, RenovateBot will update all dependencies, so we pull out the compatible dependencies into a consolidated PR to reduce disruptions and CI load.This doesn't just cover Rust dependencies but github workflows as well.
How should we test and review this PR?
This starts off with the dependency dashboard and automerging being disabled but explicitly specified to call attention to the potential for this. We can evaluate these later.
The frequency of monthly was chosen to consolidate disruptions. The main risk is doing an update right before a beta branch but we can't have a cron schedule for once every 6 weeks (I assume) which would be ideal. At least its not daily or instant.
I chose
json5
overjson
for comments and trailing commas, to make human-editing easier.I pulled the config from https://github.com/gitext-rs/git-stack/blob/main/.github/renovate.json5
CC @Turbo87