run cargo update #1587
Merged
run cargo update #1587
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
syphar
added
the
S-waiting-on-review
The last time we did a mass update, there was a memory leak in a (very) indirect dependency, which only became noticeable after running in prod under load for over a day: #1278. I don't think we have a good way to catch issues of that sort; I vaguely remember that the standard library has leaks when run under valgrind because it doesn't recognize rust-alloc, or something like that. That said, I agree 6 months is probably too infrequent - I don't mind doing it more often, we should just be especially careful with deploys that update dependencies. |
|
I ran cargo update locally and got this output: (note that this generates a slightly different Cargo.lock than the PR since crossbeam already had a release in the meantime:) diff --git a/Cargo.lock b/Cargo.lock
index b6cd36f..92c806f 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -531,9 +531,9 @@ dependencies = [
[[package]]
name = "crossbeam-channel"
-version = "0.5.1"
+version = "0.5.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "06ed27e177f16d65f0f0c22a213e17c696ace5dd64b14258b52f9417ccb52db4"
+checksum = "e54ea8bc3fb1ee042f5aace6e3c6e025d3874866da222930f70ce62aceba0bfa"
dependencies = [
"cfg-if 1.0.0",
"crossbeam-utils",
@@ -552,9 +552,9 @@ dependencies = [
[[package]]
name = "crossbeam-epoch"
-version = "0.9.5"
+version = "0.9.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "4ec02e091aa634e2c3ada4a392989e7c3116673ef0ac5b72232439094d73b7fd"
+checksum = "97242a70df9b89a65d0b6df3c4bf5b9ce03c5b7309019777fbde37e7537f8762"
dependencies = [
"cfg-if 1.0.0",
"crossbeam-utils",
@@ -565,9 +565,9 @@ dependencies = [
[[package]]
name = "crossbeam-utils"
-version = "0.8.5"
+version = "0.8.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "d82cfc11ce7f2c3faef78d8a684447b40d503d9681acebed6cb728d45940c4db"
+checksum = "cfcae03edb34f947e64acdb1c33ec169824e20657e9ecb61cef6c8c74dcb8120"
dependencies = [
"cfg-if 1.0.0",
"lazy_static",
@@ -984,6 +984,15 @@ version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4443176a9f2c162692bd3d352d745ef9413eec5782a80d8fd6f8a1ac692a07f7"
+[[package]]
+name = "fastrand"
+version = "1.6.0"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "779d043b6a0b90cc4c0ed7ee380a6504394cee7efd7db050e3774eee387324b2"
+dependencies = [
+ "instant",
+]
+
[[package]]
name = "filetime"
version = "0.2.15"
@@ -3880,13 +3889,13 @@ dependencies = [
[[package]]
name = "tempfile"
-version = "3.2.0"
+version = "3.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "dac1c663cfc93810f88aed9b8941d48cabf856a1b111c29a40439018d870eb22"
+checksum = "5cdb1ef4eaeeaddc8fbd371e5017057064af0911902ef36b39801f67cc6d79e4"
dependencies = [
"cfg-if 1.0.0",
+ "fastrand",
"libc",
- "rand 0.8.4",
"redox_syscall",
"remove_dir_all 0.5.3",
"winapi 0.3.9",That seems like too many crates to reasonably have dependabot open PRs for all of them, and I'm hesitant to remove Cargo.lock altogether since it makes the build very hard to reproduce. So I think periodic PRs with a mass update are the best alternative. |
But that's good to know. Now as you're saying it I also vaguely remember something about this.
Then I'll do it more regularly.
Yeah, true. I see crates.io is using renovate for this, which seems to do a merged lockfile maintenance PR, but until we get that I can just do it manually. While some features of dependabot are really nice (for example pulling the changelog into the PR description), the amount of dependencies ( and so dependabot PRs and commits) would be quite much noise in this repo. |
|
I hope subsequent |
|
@Nemo157 what can we do to get this forward? Split into smaller pieces? How to split? |
|
I think despite this being a pretty massive update, we can probably deploy it as is, just plan not to deploy anything else for a few days to keep an eye out for issues. |
Nemo157
approved these changes
Jan 13, 2022
syphar
added
S-waiting-on-deploy
|
I'll merge & deploy this tomorrow morning, so I can watch the server while working. |
syphar
removed
the
S-waiting-on-deploy
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Creating this also as a note to myself.
Were there specific reasons why we don't just regularly run
cargo update? I would assume when everything compiles and tests pass we're fine.If updates broke prod in the past there is probably a gap in the tests, which we could fill.
Looking back, I saw some commits that specifically updated some packages (3bfdc65), but others that look like they just update everything compatible (94daab5)