830a6e1b0c
We were using an outdated CBOR crate for MSRV reasons. But this old crate is causing suprious test failures. So delete it. (Sadly, updating the crate doesn't fix the issue, replacing it with ciborium breaks our MSRV tests because it needs a more recent `half` dependency, and replacing it with `minicbor` doesn't work because minicbor is not based on serde. So we don't really have any options.) In general, I am suspicious of this decode-then-reencode test. CBOR has some ambiguity in integer encoding. Empirically it has seemed to work for a long time, but this seems more like an indictment of our test than a positive result. Also, round-trip testing serde encoding of a byte vector is probably not a great use of our fuzz resources. I don't believe we have ever had a problem with this. Fixes #2801 |
||
|---|---|---|
| .. | ||
| README.md | ||
| coveralls.yml | ||
| cron-daily-fuzz.yml | ||
| cron-daily-kani.yml | ||
| cron-semi-weekly-update-nightly.yml | ||
| cron-weekly-rustfmt.yml | ||
| gh-release.yml | ||
| manage-pr.yml | ||
| release.yml | ||
| rust.yml | ||
| shellcheck.yml | ||
README.md
rust-bitcoin workflow notes
We are attempting to run max 20 parallel jobs using GitHub actions (usage limit for free tier).
ref: https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration
The minimal/recent lock files are handled by CI (rust.yml).
Jobs
Run from rust.yml unless stated otherwise. Total 21 jobs but
Prepare is quick and must be run first anyway.
PrepareStable - minimalStable - recentNightly - minimalNightly - recentMSRV - minimalMSRV - recentLintDocsDocsrsBenchASANWASMschemarsArch32bitCrossEmbeddedKaniCoveralls- run bycoveralls.ymlrelease- run byrelease.ymllabeler- run bymanage-pr.yml