Enable formatting in CI by doing:
- Add a section to the `test.sh` scripts to run the formatter (guarded by
the env variable `DO_FMT`) for all crates (bitcoin, hashes, internals).
- Add `DO_FMT` to the nightly `Tests` CI job.
41f2dcf6ae Improve test coverage for docs build (Tobin C. Harding)
b4c14a4b7c hashes: Use automatic link (Tobin C. Harding)
96e8a080d1 ci: Remove redundant || exit (Tobin C. Harding)
Pull request description:
Currently the docs build commands in `hashes` and `bitcoin` differ, they should be the same.
Add a command `cargo doc` to improve coverage e.g., recently we botched the feature guarding but since CI only runs `cargo rustdoc` with custom compiler conditional set we didn't catch it.
Done after seeing: https://github.com/rust-bitcoin/rust-bitcoin/pull/1504 and CI should fail on this PR until 1504 is in.
ACKs for top commit:
apoelstra:
ACK 41f2dcf6ae
Kixunil:
ACK 41f2dcf6ae
Tree-SHA512: 7cde68292cfc6f32b75d066e188e7c418ee251f9a5abc57fbd642ba33e9cd5bd8ef7c5ba7cffd206acae6ddec2f8c3db38c8c911a4319e979158666b8225953d
When we merged `hashes` into `rust-bitcoin` we ran the test script a
couple of times using `./hashes/contrib/test.sh` this causes the `cargo`
commands in the CI script to be run from the crate root which is not
what we want.
This showed up recently because `cargo test` was getting run in
`bitcoin` after building with address/memory sanitazation configured
into the build.
While we are at it run `cargo clean` after the last sanitizer build just
to future proof the CI script in case we later accidentally re-use the same
build with plain old `cargo` (without `-Zbuild-std etc.`).
Currently the docs build commands in `hashes` and `bitcoin` differ, they
should be the same.
Add a command `cargo doc` to improve coverage e.g., recently we botched
the feature guarding but since CI only runs `cargo rustdoc` with custom
compiler conditional set we didn't catch it.
Run docs in CI using nightly and stable toolchains as required.
3372333865 Add a kani badge to the README (Tobin C. Harding)
3d2a62fdd5 Run kani daily on a schedule (Tobin C. Harding)
Pull request description:
Running kani takes ages, instead of running it on every pull request we can just run it daily.
ACKs for top commit:
sanket1729:
ACK 3372333865
apoelstra:
ACK 3372333865
Tree-SHA512: 63f71155eb3f2dd9bfbc3733c407c80b59a019d356127efc6d65cf53b517f15ddd8afd92d89f968734a508882eabbf720757d95c04d688438b762bb55a22f601
4201612837 Use dtonlnay instead of actions-rs (Tobin C. Harding)
Pull request description:
Done on top of #1508
Currently we use the `actions-rs` GitHub action to run our tests. It seems the project is now unmaintained [0].
Well known Rust developer dtonlnay maintains a GitHub action that can be used instead.
Replace all uses of `actions-rs/toolchain` with `dtonlnay/rust-toolchain`. Note that with the new action there is no way to configure the toolchain, instead a different `uses` statement is required - this means we have to split our jobs up by toolchain. This is arguably cleaner anyways.
Note that with this patch applied the "no-std" tests are now _not_ run for MSRV since we explicitly support "no-std" only for the 1.47 and above toolchains - strange that this was working?
[0] https://github.com/actions-rs/toolchain/issues/216
ACKs for top commit:
sanket1729:
ACK 4201612837. Verified that we did not miss any checks in the translation.
elichai:
ACK 4201612837
Tree-SHA512: 117b35953c7e0d93ff1ea76fbff948d9a50aff9b3d0854beced540321f84eb83510af23067ff2ebc29b8d9c59b3ca205beeecde6e968bc619e21430b951f02cb
Currently we use the `actions-rs` GitHub action to run our tests. It
seems the project is now unmaintained [0].
Well known Rust developer dtonlnay maintains a GitHub action that can be
used instead.
Replace all uses of `actions-rs/toolchain` with
`dtonlnay/rust-toolchain`. Note that with the new action there is no way
to configure the toolchain, instead a different `uses` statement is
required - this means we have to split our jobs up by toolchain. This is
arguably cleaner anyways.
Note that with this patch applied the "no-std" tests are now _not_ run
for MSRV since we explicitly support "no-std" only for the 1.47 and
above toolchains - strange that this was working?
[0] https://github.com/actions-rs/toolchain/issues/216
This patches `bitcoin_hashes` to use the version in the repository and
fixes the code after removal of `Deref`.
This also turns off `AS_DEPENDENCY` check with the intention to refactor
it later.
We would like to bring the `bitcoin_hashes` crate into the
`rust-bitcoin` repository.
Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all
the commit history from the original crate but if we archive the
original repository then the history will be preserved. We maintain the
same version number obviously and in the changelog we note the change of
repository.
Commit hash that was tip of `bitcoin_hashes` at time of import:
commit 54c16249e06cc6b7870c7fc07d90f489d82647c7
Includes making `embedded` and `fuzzing` per-crate i.e., move them into
`bitcoin` as hashes includes these also.
NOTE: Does _not_ enable fuzzing for `hashes` in CI.
Notes on CI:
Attempts to merge in the github actions from the hashes crate however reduces
coverage by not running hashes tests for beta toolchain. Some additional
work could be done to improve the CI to increase efficiency without
reducing coverage. Leaving for another day.
Currently we use the `Uint256` type to represent two proof of work
integers, namely target and difficulty (work).
It would be nice to not have a public integer type that is not fully
implemented (i.e., does not implement arithmetic etc as do integer types
in stdlib). Instead of implementing all the stdlib functions we can
instead add two new wrapper types, since these are not general purpose
integers they do not need to implement anything we do not need to use.
- Add a `pow` module.
- Put a modified version of `Uint256` to `pow`.
- Add two new wrapper types `Target` and `Difficulty`.
- Only implement methods that we use on each type.
Note this patch does not remove the original `Uint256`, that will be
done as a separate patch.
Currently we run clippy in CI using a github action. The invocation has
a couple of shortcomings
1. it does not lint the tests (this requires `--all-targets`)
2. it does not lint the examples
I could not find a way to lint the examples without explicitly linting
each example by name.
Move the clippy control to `test.sh` and add an env var `DO_LINT` to
control it. Remove the explicit CI job and run the linter during the
`Test` job using the stable toolchain.
Add a clippy configuration file configuring the MSRV. Add a github
actions job to run clippy on CI.
Please note the job does _not_ use `--all-targets` because doing so
causes:
```
error[E0554]: `#![feature]` may not be used on the stable release channel
--> src/lib.rs:46:54
|
46 | #![cfg_attr(all(test, feature = "unstable"), feature(test))]
```
We currently build the docs as a separate CI job, we can however just do
it as part of the `Tests` job using the nightly toolchain.
Conditionally build the docs based on a `DO_DOCS` env var.
Note, uses `--cfg docsrs` so can only be built run with nightly toolchain.
I think this might take a while to resolve and we should move ahead with
1.58. Looks like the fresh release of 1.59 added LLVM 13.0 that broke
some things.
Disable problematic jobs that involve Github Actions caching or `cross`
whenever the environment is set to ACT. This allows running the CI
pipeline locally and hopefully speeds up PR cycle times by reducing
unexpected CI pipeline results.
Based on the original work by Justin Moon.
*MSRV unchanged from 1.29.0.*
When `std` is off, `no-std` must be on, and we use the [`alloc`](https://doc.rust-lang.org/alloc/) and core2 crates. The `alloc` crate requires the user define a global allocator.
* Import from `core` and `alloc` instead of `std`
* `alloc` only used if `no-std` is on
* Create `std` feature
* Create `no-std` feature which adds a core2 dependency to polyfill `std::io` features. This is an experimental feature and should be
used with caution.
* CI runs tests `no-std`
* MSRV for `no-std` is 1.51 or so
Tobin C. Harding
Andrew Poelstra
Martin Habovstiak
mcroad
sanket1729
Andrew Ahlers
Dr Maxim Orlovsky
Riccardo Casatta
Devrandom
Sebastian Geisler