ci: automated update to rustc 1.83.0#1776
Conversation
42f270a to
ed88439
Compare
|
This doesn't need to go into the final 1.0.0, but if folks have time to review it I'd like to get it in so:
|
aa83307 to
74a7f73
Compare
crates/chain/Cargo.toml
Outdated
| proptest = "1.2.0" | ||
| bdk_testenv = { path = "../testenv", default-features = false } | ||
| criterion = { version = "0.2" } | ||
| criterion = { version = "0.5" } |
There was a problem hiding this comment.
I'm not aware of the reason it has been downgraded to 0.2 by #1670, but I guess there might be some #:thinking:
There was a problem hiding this comment.
I manually ran the bench tests with criterion 0.5 and they still build and run so I think it's ok. @ValuedMammal do you know why we were using such an old version?
There was a problem hiding this comment.
AFAICT on VM's initial PR it was using 0.5 🤔.
There was a problem hiding this comment.
do you know why we were using such an old version?
I think it was only to get CI to pass using MSRV. I guess the issue didn't surface on #1735 because running the benches required a special invocation and so criterion was not automatically linked in with the build deps.
| cargo update -p indexmap --precise "2.5.0" | ||
| - name: Build | ||
| run: cargo build --workspace --exclude 'example_*' ${{ matrix.features }} | ||
| run: cargo build --workspace --exclude 'example_*' --exclude 'bdk_testenv' ${{ matrix.features }} |
There was a problem hiding this comment.
I'm divided on this one, it surely helps not pinning on CI, but I'm unsure if we should test or not on MSRV toolchain 🤔.
There was a problem hiding this comment.
Since we are keeping such an old MSRV and our test deps change so often I think this is the only way to manage it. But I'm open to move this to a different PR for after 1.0 if this is going to need more discussion.
|
@notmandatory It's probably needed to update the docs nightly toolchain too, see https://github.com/bitcoindevkit/bdk/actions/runs/12360406444/job/34495287138#step:7:307 |
There was a problem hiding this comment.
I've run the workflows with act tool locally, but the output is not clear.
Though the CI is green, and have reviewed the output there.
If there are better ways to check this, please let me know.
Besides that, I have to research more about best practices on MSRV, as it seems to be another deep rabbit hole. The best material I have found so far is this discussion in the api guidelines repository of rust-lang. The stance adopted there seems to be in favor of pinning dependencies but in an alternative Cargo.lock.min file, which I think is not very different from what what was done here before, and I think is a path we should consider, probably against the original motivation of this PR.
However, I think these changes doesn't go in the opposite direction the link I mentioned above goes, and considering the project is still checking it builds against MSRV, my only concern here is the lack of testing this introduces for MSRV, so I wouldn't remove them unless there are strong reasons to remove the pinning and remove the testing in the way.
Good call. I updated the docs job to use rust |
d4dc092 to
b287325
Compare
b287325 to
272ce22
Compare
I removed the commits that changed our MSRV testing and dependencies. I agree this is a rabbit hole that deserves more work to get right. |
I haven't tried the |
Automated update to Github CI workflow
cont_integration.ymlby create-pull-request GitHub actionI manually fixed new clippy warnings.
I also changed CI to:
1. not build or run tests or test dependencies when building with MSRV. This reduced the number of dependencies we need to pin for MSRV and fixes 1398.I removed these changes.2. use the same version or rust as in the
rust-versionfile for all jobs instead of just for clippy. I made this change to prevent CI breaks when stable changes before we have a chance to fix the auto created PR that bumps therust-versionfile.