It has been argued that the API files provide value for verifying that
code changes produce API changes in the expected way. This helps devs
and reviewers.
It has also been argued that the CI job adds friction and forces devs
to configure their environment unnecessarily.
Both viewpoints have some merit.
Lets remove the API files for now, and when we start doing 1.0-alpha
releases and can start to expect minimal API breaking changes (and
therefore minimal need to use the tooling).
Add a script to generate API files using `cargo public-api` for the
crates that we are trying to stabalise (the so called 'leaf crates').
- hashes
- io
- primitives
- units
We already ran the script and committed the files last patch. The fact
that this patch does not include any changes to the `api/` directory and
that CI passes is enough to convince us that last patch was valid.
Add a CI job that runs the script and checks there are no changes to
the committed text files thereby proving no API changes are made in a
PR without explicitly modifying the API text files.
Add documentation to `CONTRIBUTING.md` on what is expected of devs.
The only reason we need `hex-conservative` is to parse strings and
format them as hex. For users that do not require this functionality we
can make the `hex-conservative` crate an optional dependency.
The `serde` feature requires `Display` so we enable `hex` from the
`serde` feature.
If `hex` feature is not enabled we still need to be able to debug so
provide `fmt::Debug` functionality by way of macros.
Close: #2654
Recently we discovered a bug in the `run_task` script where we forgot to
use `--no-default-features` in a subset of test runs (the feature matrix
stuff).
Upgrade to use the latest version of `run_task.sh`.
Instead of manually setting the crates list it is less error prone to do
so mechanically. This required some changes to the `run_task` script
which have now merged, so we update to use the new commit hash at the
same time.
- Use shell to set the `CRATES` env var used by `run_task.sh`.
- Use latest revision of rust-bitcoin-maintainer-tools
Apparently the `checkout` action will just grab random shit in the case
that you configure it with an unknown key. There is a warning in the
middle of the CI output so ok, I guess there's that.
This commit does not change the pinned version of
rust-bitcoin-maintainer-tools, though we do want to update the pin,
because I want to make sure that the pin is actually working.
The version 1.63 satisfies our requirements for MSRV and provides
significant benefits so this commit bumps it. This commit also starts
using some advantages of the new MSRV, namely namespaced features, weak
dependencies and the ability to use trait bounds in `const` context.
This however does not yet migrade the `rand-std` feature because that
requires a release of `secp256k1` with the same kind of change - bumping
MSRV to 1.63 and removing `rand-std` in favor of weak dependency.
So that updates don't break our CI setup used a specific version of
`cargo-public-api`, this means we will have to update it manually
periodically though.
For now, since the latest release just broke us, use the release from a
month ago.
We have a mechanism to run additional custom tests by way of the
`extra_tests.sh` script in each crate.
Remove the CI job and run the schemars test using `extra_tests.sh`. This
patch changes the test coverage because currently the schemars test is
only run with a stable toolchain but with this patch applied it runs
with stable, MSRV, and nightly.
Fix: #2787
Add a document start and comment to help try to stop the readme from
going stale.
This removes a `yamllint` warning.
While we are clearing lint warnings disable the one causing
warning truthy value should be one of [false, true] (truthy)
This is a know issue with GitHub actions yaml because `on` is a yaml
keyword, or something like that.
As we did for the wasm job.
In preparation for using the `run_task` script from maintainer tools we
want to have all the things that are particular to `rust-bitcoin` out of
the current `run_task` script.
The address/memory sanitizer test is specific to `hashes`. Add a script
in `hashes/contrib` and call it from the ASAN job.
No test coverage change.
In preparation for using the `run_task` script from maintainer tools we
want to have all the things that are particular to `rust-bitcoin` out of
the current `run_task` script.
The wasm test is specific to `hashes`. Add a script in `hashes/contrib`
and call it from the wasm job.
No test coverage change.
I've been a bit confused lately about pinning and the locks, at some
stage recently I changed 'Set dependencies' to 'Copy lock file'. Its no
biggy but the original that Kix wrote was correct and descriptive - it
was me who was confused. Revert it back to the original.
Recently we re-wrote CI to increase VM level parallelism, in hindsite
this has proved to be not that great because:
- It resulted in approx 180 jobs
- We are on free tier so only get 20 jobs (VMs) at a time so its slow to run
- The UI is annoying to dig through the long job list to find failures
Have another go at organising the jobs with the main aim of shortening
total run time and making it easier to quickly see fails.
Re-write the `run_task.sh` script, notable moving manifest handling
to the workflow. Also don't bother testing with beta toolchain.
WASM Note
Removes the `cdylib` and `rlib` from the manifest patching during wasm
build - I do not know the following:
- Why this breaks on this PR but not on other PRs
- Why I can't get wasm test to run locally on master but PRs are passing
- What the `cdylib` and `rlib` were meant to be doing
This is the docs from: https://doc.rust-lang.org/reference/linkage.html
* --crate-type=cdylib, #![crate_type = "cdylib"] - A dynamic system
library will be produced. This is used when compiling a dynamic library
to be loaded from another language. This output type will create *.so
files on Linux, *.dylib files on macOS, and *.dll files on Windows.
* --crate-type=rlib, #![crate_type = "rlib"] - A "Rust library" file
will be produced. This is used as an intermediate artifact and can be
thought of as a "static Rust library". These rlib files, unlike
staticlib files, are interpreted by the compiler in future linkage. This
essentially means that rustc will look for metadata in rlib files like
it looks for metadata in dynamic libraries. This form of output is used
to produce statically linked executables as well as staticlib outputs.
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.
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.
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.
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
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
- 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.
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