Use an explicit rev for oxidecomputer git deps#1936
Merged
Merged
Conversation
Chasing down a cargo build failure in propolis caused by multiple versions of the same package lead to the discovery that rev of omicron that is in propolis' lock file is old, about 700 commits behind main. Once propolis was updated to the same rev of omicron that crucible uses, cargo no longer hit that same build error. Use explicit git revs in Cargo.toml: this doesn't change the version in the lock file but does make it explicit what is being used. Propolis will be updated shortly to pull this commit in (a no-op, as the lockfile version doesn't change), and will be updated to use explicit revs in the same way.
leftwo
approved these changes
May 14, 2026
Contributor
leftwo
left a comment
There was a problem hiding this comment.
Does this just make it obvious that we are not updating these dependencies?
because of the lock file, it means that we get "main" from whatever time the lockfile has and it won't be updated unless someone does something to update it?
Also, renovate, should it be tracking this?
Contributor
Author
yeah, it's basically moving the information into the much more readable Cargo.toml.
Maybe! Not sure :) |
jmpesp
added a commit
to oxidecomputer/propolis
that referenced
this pull request
May 14, 2026
Bump crucible rev to latest, and use explicit revs Pick up the following Crucible PRs: - Use an explicit rev for oxidecomputer git deps (oxidecomputer/crucible#1936) - Add Clone and Deserialize to VolumeInfo et al (oxidecomputer/crucible#1935) - Update omicron/oximeter (oxidecomputer/crucible#1933) - [meta] update to drift 0.1.4 (oxidecomputer/crucible#1932) - Don't log if there is nothing to log (oxidecomputer/crucible#1930) Also, similar to oxidecomputer/crucible#1936, switch the omicron related dependencies from 'branch = "main"' to an explicit rev. Previous to this commit, _two_ old versions of omicron were being pulled in: `becbbb61` and `b8efb9a0`. The first one is about 300 commits behind, and the second is about 700 commits behind. With explicit git revs, the rev being used moves to Cargo.toml, and is known without digging into the lockfile. Related, the tokio dep had to be further specified in order to build.
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
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.
Chasing down a cargo build failure in propolis caused by multiple versions of the same package lead to the discovery that rev of omicron that is in propolis' lock file is old, about 700 commits behind main. Once propolis was updated to the same rev of omicron that crucible uses, cargo no longer hit that same build error.
Use explicit git revs in Cargo.toml: this doesn't change the version in the lock file but does make it explicit what is being used. Propolis will be updated shortly to pull this commit in (a no-op, as the lockfile version doesn't change), and will be updated to use explicit revs in the same way.