Test with minimal dependency versions#1272
Test with minimal dependency versions#1272Kixunil wants to merge 1 commit intorust-bitcoin:masterfrom
Conversation
|
|
|
Oh, I see now, they kept in an alias. |
apoelstra
left a comment
There was a problem hiding this comment.
ACK ffdb2f489441020a9e57d73ee1dd7910b34992a0
|
Oh, is this actually correct? From my understanding of |
|
I think https://github.com/rust-bitcoin/rust-bitcoin/actions/runs/3053748075/jobs/4924768120 is doing the right thing? |
|
It seems to be only testing with 1.47. Am I missing something? |
|
Oh, you're right -- I just looked for "is it actually doing the Maybe somebody else here understands GH Actions but unfortunately you may just have to iterate a dozen times until you guess how to make it do what you want.. |
|
I will re-read the docs and retry and then start pinging people if it still doesn't work. :) |
e6d508d to
371acd5
Compare
It could happen that we unknowingly depend on a new version of a crate without updating `Cargo.toml`. This could couse resolution issues for downstream users. It's also unclear for outsiders to know with which dependencies did we test the crate. This change commits two lock files: `minimal` and `recent`. `minimal` contains minimal depdendency versions, while `recent` contains dependency versions at the time of making the change. Further, this adds CI jobs to test with both lock files, CI job for `internals` crate, removes old `serde` pinning and prints a warning if `recent` is no longer up to date. (We may have to override it somehow if any crate breaks MSRV.) The documentation is also updated accordingly. Closes rust-bitcoin#1230
|
It looks like it works. I've moved duplicate checking to lint part. (I'd love to have a separate linting job but that's for another time.) |
|
|
||
| ## External dependencies | ||
|
|
||
| The crate integrates with a few external librarie, most notably `serde`. These |
There was a problem hiding this comment.
| The crate integrates with a few external librarie, most notably `serde`. These | |
| The crate integrates with a few external libraries, most notably `serde`. These |
| cd "$crate" | ||
| ./contrib/test.sh | ||
| ) | ||
| done |
There was a problem hiding this comment.
Perhaps to catch future mistakes when editing the test scripts we could add
if ! diff Cargo-$dep.lock Cargo.lock
then
echo "::warning Cargo.lock has been updated by test run - check for missing --locked flag"
exit 1
fi| then | ||
| echo Dependencies are up to date | ||
| else | ||
| echo "::warning file=Cargo-recent.lock::Dependencies could be updated" |
There was a problem hiding this comment.
Can I ask, why the double colons in ::warning? We could use colors
echo "\e[33mWarning:\e[0m ..."
There was a problem hiding this comment.
This is a special signal for GitHub to show the warning at that file. Sadly one will only see it when explicitly looking at the file but that's still better than looking into logs.
There was a problem hiding this comment.
Oh cool, cheers - I've never seen that before.
There was a problem hiding this comment.
Me neither, I just thought "is there a way to warn in GH actions?" and succeeded googling it. :)
|
|
||
| if [ "$DO_LINT" = true ] | ||
| then | ||
| cargo clippy --frozen --all-features --all-targets -- -D warnings |
There was a problem hiding this comment.
Why use --frozen over --locked, is it because we know the order of CRATES so we know that cargo has already been run with --locked so doesn't need to hit the network again?
There was a problem hiding this comment.
I previously thought --frozen does something else. I changed it to --locked but forgot in this case.
|
Any reason for all the manual file handling? I was just hoping to eventually get something like: https://github.com/fedimint/fedimint/pull/580/files working . Done automatically in the CI. |
|
@dpc Mainly I wanted for people to be able to see the tested versions somewhere. I also fear that some nightly will change |
I don't know the details, but isn't min-version checking ... kind of a best effort thing anyway? |
Given we run whole test suite against them I don't think so. :) |
|
I like this approach, because as @Kixunil says, you can see exactly the lockfile that's being used. If it breaks more than once due to cargo changing its format maybe we'll have to revisit our approach. Edit interesting idea @dpc to use |
Can you please elaborate or paste some links? I don't understand what exactly changed. I see the point or bitcoin being so widely used core library for Bitcoin Rust ecosystem that it needs a solid check here. However I'm for other projects, I'm always reluctant putting extra manual steps on the contributors. |
|
If I remember correctly a lock file produced by current MSRV can't be read by old rust-bitcoin MSRV - 1.29. You have to delete it and re-generate. If similar thing happened in nightly it'd break us. I don't actually want contributors to randomly update dependencies. :) If it's really required we will figure it out together. |
|
Yes, there was definitely a break I remember around 1.30 or so which caused us no end of grief with the old MSRV, but I can't think of another time. So it's rare at least. And it may be that after the noise people made last time, they won't do it again :P |
sanket1729
left a comment
There was a problem hiding this comment.
strong concept ACK. Agree with all of @tcharding's suggestions
|
Oh, I just remembered a good reason to not just |
|
Conflicts with #1729 |
|
cc rust-bitcoin/rust-secp256k1#591 which does something similar (but does not actuall test) in rust-secp |
|
Have you time to bring this back to life @Kixunil or would you like me to pick it up for you? |
|
I'm pretty busy lately, feel free to take it if you have time! |
|
No worries man, will get to it shortly. Cheers. |
|
I picked up this PR over at #1764 |
c4c64c0 Test with minimal dependency versions (Martin Habovstiak) d5655d5 Bump core2 dependency from 0.3.0 -> 0.3.2 (Tobin C. Harding) Pull request description: This is work originally done by Kixunil in #1272, I picked it up to help out. The only changes I made were rebasingg, updating the recent lock file, adding `--locked` to hashes contrib file, and adding a co-developed-by tag for accountability. It could happen that we unknowingly depend on a new version of a crate without updating `Cargo.toml`. This could cause resolution issues for downstream users. It's also unclear for outsiders to know with which dependencies did we test the crate. This change commits two lock files: `minimal` and `recent`. `minimal` contains minimal dependency versions, while `recent` contains dependency versions at the time of making the change. Further, this adds CI jobs to test with both lock files, CI job for `internals` crate, removes old `serde` pinning and prints a warning if `recent` is no longer up to date. (We may have to override it somehow if any crate breaks MSRV.) The documentation is also updated accordingly. Closes #1230 ACKs for top commit: apoelstra: ACK c4c64c0 Kixunil: ACK c4c64c0 Tree-SHA512: 7d386e96ab747f6a6bafeea828ac65bd8bb11975eaa3408acecac369cd2f235f6e9d4c57202be18a3dc2eeb2a2df532d73e4d35cd1f3fbf092eb6414c55b1524
It could happen that we unknowingly depend on a new version of a crate without updating
Cargo.toml. This could couse resolution issues for downstream users. It's also unclear for outsiders to know with which dependencies did we test the crate.This change commits two lock files:
minimalandrecent.minimalcontains minimal depdendency versions, whilerecentcontains dependency versions at the time of making the change.Further, this adds CI jobs to test with both lock files, CI job for
internalscrate, removes oldserdepinning and prints a warning ifrecentis no longer up to date. (We may have to override it somehow if any crate breaks MSRV.)The documentation is also updated accordingly.
Closes #1230