Version `0.49` of `kani` broke our daily CI job, there is now a new
release out that fixes the issue.
Remove the explicit `kani` version so we pull the latest version.
Kani version `0.49.0` came out 10 days ago, its odd that our CI just
broke today but in an attempt to see if its release related pin to the
version before the latest release.
The nightly pinning is used by a bunch of different tools outside of
github actions, move the config file to the crate root.
Update the path in the justfile.
Done in preparation for fixing the git pre-commit hook.
Waiting for the fuzzer slows down the dev feedback loop because it makes
CI slow. We still want fuzz coverage but not in a way that slows down
devs.
Instead of running the fuzzer on every PR just run it once a nightly.
As we do for other daily jobs, rename the yaml file to make explicit
what it does.
Open questions:
- This should run for 30 minutes but I can't work out why the current
set up only runs for a shorter time than that?
- Is this less fuzzing i.e., is 30 minutes once a day better or worse that 1
minute 30 times?
32f9b1a231 ci: gate coverage analysis on whether source code changed (Andrew Poelstra)
2203c02347 ci: gate fuzztesting on whether source code changed (Andrew Poelstra)
09f7fc3cff ci: gate CI workflow on source being changed (Andrew Poelstra)
9aca8a18c7 ci: introduce `classify-pr.sh` script which determines whether a PR should have CI run (Andrew Poelstra)
Pull request description:
Fixes#2523
ACKs for top commit:
tcharding:
ACK 32f9b1a231
Tree-SHA512: 7d53365bdf4e8ae5480221e43b4c515d4b16048ec1a00cb62ab65b2d2b91a37f8945c39b619a82bfe4ca74f3508176d9879481b908bb8d3fe8d214b173d3bf18
The chatbot says this should cause CI to trigger on the nightly update
PRs. With the default token this does not happen because it has the
potential to cause recursive CI actions. (How this is avoided by using a
PAT, I don't know, but whatever.)
Currently we do not build the code in the kani tests when PRs are
pushed, instead we run the verifier once a day. We should at least check
the code builds on each PR. One way to do this is to build the proofs
without running them, `kani --only-codegen` does that.
c6c5f07880 Add automated labeler job (Martin Habovstiak)
Pull request description:
Rather than modifying the labels manually, which we often forget, we can label the PRs automatically. This will make it easier to search PRs.
ACKs for top commit:
apoelstra:
ACK c6c5f07880
tcharding:
ACK c6c5f07880
Tree-SHA512: d3f7ca8c69cc8734d914f871675568ca293e28c3dc7351ee54b9237645204b87d1b47db02863b27d930900ae4b41d6f169f130ed9f4c750d4afbb765921cfb66
396e049a7a Use InputString instead of String (Tobin C. Harding)
acacf45edf Add ParseDenominationError (Tobin C. Harding)
69e56a64ed Add bitcoin-units crate (Tobin C. Harding)
4ecb1fe7da internals: Add docs to InputString (Tobin C. Harding)
fa8d3002cd internals: Fix docs typo (Tobin C. Harding)
Pull request description:
Create a new `bitcoin-units` crate as described [here](https://github.com/rust-bitcoin/rust-bitcoin/issues/550#issuecomment-1012103022).
Only the `amount` module is currently included.
I've resolved the `Encodale/Decodable` issue by keeping the `amount` module in `bitcoin`.
ACKs for top commit:
Kixunil:
ACK 396e049a7a
apoelstra:
ACK 396e049a7a
Tree-SHA512: caf5e9da0458435ab19d00d4506896257e898525a4472d435fdac1d1a37bb747befd56993b106673f938475e5777d952a13ba04a2d3cb710d7afe7f5faebb7b8
While `clippy` now allows `TBD` to be used in `since` parameter of
`deprecated` attribute it is only available in the newest, nightly,
version. Switch `clippy` version to nightly to enable the `TBD` value.
Currently `bitcoin` cannot be built with no features enabled, it must
have either "no-std" or "std" enabled. This is an artifact from when
we depended on `core2` for "no-std", now that we have our own `io` crate
and we unconditionally depend on it we can remove the "no-std" feature.
6a9713a0cc Add author for the format bot (Tobin C. Harding)
Pull request description:
The format bot defaults to using the person who triggered the workflow. We can use the `author` option to configure a dummy bot author.
ACKs for top commit:
Kixunil:
ACK 6a9713a0cc
apoelstra:
ACK 6a9713a0cc
Tree-SHA512: 8b2c419767d217ddb499032497f46588f939d92a01694b611ad44d872541871da28cfe3e9edd0c917bfdea02e86f8ed3a4fdfef60b59d0be5b7c0c2814a5db7b
Rust version 1.56.0 introduced edition 2021. Shortly afterwards, on
October 21 2021 Rust version 1.56.1 was released.
Debian stable is currently shipping `rustc 1.63.0`.
Our stated MSRV policy is: In Debian stable and at least 2 years old.
Therefore our MSRV policy is met by Rust version 1.56.1 and we can strat
to bump our MSRV org wide.
Start by bumping the `rust-bitcoin` and `hashes` MSRV to Rust 1.56.1,
includes:
- Update docs.
- Update CI and remove pinning.
- Update the build files and remove now stale cfg attributes rust_v_1_x
for values less than the new MSRV.
- Use new `IntoIterator` for arrays so we no longer need to allocate a
vector to iterate.
Links:
- https://blog.rust-lang.org/2021/11/01/Rust-1.56.1.html
- https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html
- https://packages.debian.org/stable/rust/rustc
old: `actions-rs/toolchain`
new: `dtolnay/rust-toolchain`
fix
ci(fuzz): change runner to ubuntu-latest
ci: update run syntax in fuzz job
ci: update and run fuzz/generate-files.sh
c34c709681 CI: add an automated github releases on new tags (Einherjar)
Pull request description:
Creates a `gh-release.yml` that runs on every new tag using the [`ncipollo/release-action`](https://github.com/ncipollo/release-action), which is one of the recommended actions after [GitHub's official `actions/create-release`](https://github.com/actions/create-release) was archived.
The idea is to just have a release with the source code, no binary (although if wanted I can add that as well).
A little bit of context: tcharding told me yesterday at TABConf that he copied manually all commits titles to the release notes somewhere (I think in crates.io?).
This is an easy way to do it, just copy from the GitHub release.
Finally, it is also positive to generate Releases from Tags since this increases the exposure of the repo (GitHub is highly social) while also signaling maturity.
Here's an [example](https://github.com/oven-sh/bun/releases/tag/bun-v0.8.1) that I've found in a non-related repo that has the same `generateReleaseNotes: true` as this PR proposes
<img width="857" alt="image" src="https://github.com/realeinherjar/rust-bitcoin/assets/136860407/41789514-8abf-4f58-b7ca-d2c352346923">
ACKs for top commit:
apoelstra:
ACK c34c709681
tcharding:
ACK c34c709681
Tree-SHA512: 06bc0276b5aca95e19965eadb79d0a4cf8606b222dce37f095247196fcac023458c34e35cf34fa2344bc274063e642b93b05dc796a27179567052c58ac4bc27a
c2f3c1fa11 fix(CI): rust-toolchain stable (Einherjar)
Pull request description:
- sets `dtolnay/rust-toolchain` to `stable`
- delegates the `toolchain` to `1.48.0` as GitHub action input
This will make the rust-toolchain to always run in the `stable` branch with the toolchain version being handled in the action. It will appease dependabot and we can change at any time the `toolchain` action input.
Discussed in https://github.com/rust-bitcoin/rust-bitcoin/pull/2055
ACKs for top commit:
apoelstra:
ACK c2f3c1fa11
tcharding:
ACK c2f3c1fa11
Tree-SHA512: 83637bcd73aed1210ff67376c9f99047293dd22c2b863dd5f39ba5efb65081ff2d0cce4e375abb79b33918101a12f1780c3bde78b76a29331733f5cf515d1ac7