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
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
6def5bc974 CI: Use run_task from maintainer tools (Tobin C. Harding)
c5af52847b CI: Add docs and document start (Tobin C. Harding)
62ba10503a CI: Use correct spacing (Tobin C. Harding)
0c0e88165e CI: Add README file (Tobin C. Harding)
44cb2255d3 CI: Add sanitizer script (Tobin C. Harding)
3407257936 CI: Add WASM script (Tobin C. Harding)
cc14edf63f CI: Run the schemars job directly using cargo (Tobin C. Harding)
1fb12e1917 CI: Remove recent from schemars job (Tobin C. Harding)
8d7117bb0e CI: Use original name (Tobin C. Harding)
Pull request description:
First we do some clean up, then we pull the stuff that is specific to this repo out into separate tests, then as the last patch we switch over to use the new script for `rust-bitcoin-maintainer-tools` that was introduced in https://github.com/rust-bitcoin/rust-bitcoin-maintainer-tools/pull/4.
ACKs for top commit:
apoelstra:
ACK 6def5bc974
Tree-SHA512: 70105d455294d49deb43461958435096d074d19ea8d9adc7036e15d74dfdab466f04b1d9e934574077ca0c32a6fe77d0e5aa11068d8c4d51acef634591227d33
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.
26b9782d8b CI: Re-write run_task.sh (Tobin C. Harding)
Pull request description:
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.
### Note on review
The diff is hard to read for `rust.yml`, I tried splitting out a bunch of separate patches but it resulted in the same thing (because there are so many identical lines in the yaml file). I suggest just looking at the yaml file and not the diff.
ACKs for top commit:
apoelstra:
ACK 26b9782d8b
sanket1729:
ACK 26b9782d8b.
Tree-SHA512: 1b0a0bab5cf729c5890f7150953499b42aebd3b1c31a1b0d3dfa5b5e78fda11e17a62a2df6b610ab4a950d5709f3af6fff1ae64d9e67379338903497ab77ae0e
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.
The `labeler` job has an input `sync-labels` (default `false`) that
configures:
> Whether or not to remove labels when matching files are reverted or no
> longer changed by the PR
ref: https://github.com/actions/labeler
Currently we are using the default which means labels are not synced
when a PR is modified.
Example
A PR initially touches the `hashes` and `bitcoin` crates and the labeler
action adds `C-hashes` and `C-bitcoin`. Later, a force push removes the
changes to `hashes`, the labeler will not remove the `C-hashes` label.
Now the labels are incorrect.
Note on `pull_request_target`:
We use `on: pull_request_target`, this means the action is run in the
target branch not in the PR branch. So the changes in this patch are not
run when this PR is pushed up. Therefore we cannot test this patch but
have to merge it blindly - please review carefully.
Some further security notes that I learned while doing this patch. The
`pull_request_target` has access to GitHub secrets, and in
`manage-pr.yaml` we run `./contrib/gen_label_config.sh`. This is safe
because its the version of this script on `master` that is run not the
version in the PR (so a malicious attacker cannot patch
`gen_label_config.sh` and have it be run). However we need to be aware
that we do not accidentally merge some funky shell and inadvertently
leak secrets.
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
daa70ea931 Bump actions/cache from 2 to 3 (dependabot[bot])
Pull request description:
Bumps [actions/cache](https://github.com/actions/cache) from 2 to 3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/actions/cache/releases">actions/cache's releases</a>.</em></p>
<blockquote>
<h2>v3.0.0</h2>
<ul>
<li>
<p>This change adds a minimum runner version(node12 -> node16), which can break users using an out-of-date/fork of the runner. This would be most commonly affecting users on GHES 3.3 or before, as those runners do not support node16 actions and they can use actions from github.com via <a href="https://docs.github.com/en/enterprise-server@3.0/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect">github connect</a> or manually copying the repo to their GHES instance.</p>
</li>
<li>
<p>Few dependencies and cache action usage examples have also been updated.</p>
</li>
</ul>
<h2>Updating actions/core to version 1.10.0</h2>
<p>The ::save-state and ::set-output are deprecated. The newer version of actions/core >1.10.0 uses the new syntax for save and set output. After this change, customers using actions/cache@v2 won't see deprecation warning message.</p>
<h2>v2.1.7</h2>
<p>Support 10GB cache upload using the latest version <code>1.0.8</code> of <a href="https://www.npmjs.com/package/@actions/cache"><code>@actions/cache</code> </a></p>
<h2>v2.1.6</h2>
<ul>
<li>Catch unhandled "bad file descriptor" errors that sometimes occurs when the cache server returns non-successful response (<a href="https://redirect.github.com/actions/cache/pull/596">actions/cache#596</a>)</li>
</ul>
<h2>v2.1.5</h2>
<ul>
<li>Fix permissions error seen when extracting caches with GNU tar that were previously created using BSD tar (<a href="https://redirect.github.com/actions/cache/issues/527">actions/cache#527</a>)</li>
</ul>
<h2>v2.1.4</h2>
<ul>
<li>Make caching more verbose <a href="https://redirect.github.com/actions/toolkit/pull/650">#650</a></li>
<li>Use GNU tar on macOS if available <a href="https://redirect.github.com/actions/toolkit/pull/701">#701</a></li>
</ul>
<h2>v2.1.3</h2>
<ul>
<li>Upgrades <code>@actions/core</code> to v1.2.6 for <a href="https://github.com/advisories/GHSA-mfwh-5m23-j46w">CVE-2020-15228</a>. This action was not using the affected methods.</li>
<li>Fix error handling in <code>uploadChunk</code> where 400-level errors were not being detected and handled correctly</li>
</ul>
<h2>v2.1.2</h2>
<ul>
<li>Adds input to limit the chunk upload size, useful for self-hosted runners with slower upload speeds</li>
<li>No-op when executing on GHES</li>
</ul>
<h2>v2.1.1</h2>
<ul>
<li>Update <code>@actions/cache</code> package to <code>v1.0.2</code> which allows cache action to use posix format when taring files.</li>
</ul>
<h2>v2.1.0</h2>
<ul>
<li>Replaces the <code>http-client</code> with the Azure Storage SDK for NodeJS when downloading cache content from Azure. This should help improve download performance and reliability as the SDK downloads files in 4 MB chunks, which can be parallelized and retried independently</li>
<li>Display download progress and speed</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/actions/cache/blob/main/RELEASES.md">actions/cache's changelog</a>.</em></p>
<blockquote>
<h1>Releases</h1>
<h3>3.0.0</h3>
<ul>
<li>Updated minimum runner version support from node 12 -> node 16</li>
</ul>
<h3>3.0.1</h3>
<ul>
<li>Added support for caching from GHES 3.5.</li>
<li>Fixed download issue for files > 2GB during restore.</li>
</ul>
<h3>3.0.2</h3>
<ul>
<li>Added support for dynamic cache size cap on GHES.</li>
</ul>
<h3>3.0.3</h3>
<ul>
<li>Fixed avoiding empty cache save when no files are available for caching. (<a href="https://redirect.github.com/actions/cache/issues/624">issue</a>)</li>
</ul>
<h3>3.0.4</h3>
<ul>
<li>Fixed tar creation error while trying to create tar with path as <code>~/</code> home folder on <code>ubuntu-latest</code>. (<a href="https://redirect.github.com/actions/cache/issues/689">issue</a>)</li>
</ul>
<h3>3.0.5</h3>
<ul>
<li>Removed error handling by consuming actions/cache 3.0 toolkit, Now cache server error handling will be done by toolkit. (<a href="https://redirect.github.com/actions/cache/pull/834">PR</a>)</li>
</ul>
<h3>3.0.6</h3>
<ul>
<li>Fixed <a href="https://redirect.github.com/actions/cache/issues/809">#809</a> - zstd -d: no such file or directory error</li>
<li>Fixed <a href="https://redirect.github.com/actions/cache/issues/833">#833</a> - cache doesn't work with github workspace directory</li>
</ul>
<h3>3.0.7</h3>
<ul>
<li>Fixed <a href="https://redirect.github.com/actions/cache/issues/810">#810</a> - download stuck issue. A new timeout is introduced in the download process to abort the download if it gets stuck and doesn't finish within an hour.</li>
</ul>
<h3>3.0.8</h3>
<ul>
<li>Fix zstd not working for windows on gnu tar in issues <a href="https://redirect.github.com/actions/cache/issues/888">#888</a> and <a href="https://redirect.github.com/actions/cache/issues/891">#891</a>.</li>
<li>Allowing users to provide a custom timeout as input for aborting download of a cache segment using an environment variable <code>SEGMENT_DOWNLOAD_TIMEOUT_MINS</code>. Default is 60 minutes.</li>
</ul>
<h3>3.0.9</h3>
<ul>
<li>Enhanced the warning message for cache unavailablity in case of GHES.</li>
</ul>
<h3>3.0.10</h3>
<ul>
<li>Fix a bug with sorting inputs.</li>
<li>Update definition for restore-keys in README.md</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="704facf57e"><code>704facf</code></a> Merge pull request <a href="https://redirect.github.com/actions/cache/issues/1236">#1236</a> from actions/bethanyj28/bump-version</li>
<li><a href="17e2888746"><code>17e2888</code></a> Add to RELEASES.md</li>
<li><a href="667d8fdfa2"><code>667d8fd</code></a> bump action version to 3.3.2</li>
<li><a href="f7ebb81a3f"><code>f7ebb81</code></a> Consume latest toolkit and fix dangling promise bug (<a href="https://redirect.github.com/actions/cache/issues/1217">#1217</a>)</li>
<li><a href="67b839edb6"><code>67b839e</code></a> Merge pull request <a href="https://redirect.github.com/actions/cache/issues/1187">#1187</a> from jorendorff/jorendorff/rm-add-to-project</li>
<li><a href="57f0e3f198"><code>57f0e3f</code></a> Remove actions to add new PRs and issues to a project board</li>
<li><a href="04f198bf0b"><code>04f198b</code></a> Merge pull request <a href="https://redirect.github.com/actions/cache/issues/1132">#1132</a> from vorburger/bazel-example</li>
<li><a href="bd9b49b6c3"><code>bd9b49b</code></a> Merge branch 'main' into bazel-example</li>
<li><a href="ea0503788c"><code>ea05037</code></a> Merge pull request <a href="https://redirect.github.com/actions/cache/issues/1122">#1122</a> from actions/pdotl-patch-1</li>
<li><a href="6a1a45d49b"><code>6a1a45d</code></a> Merge branch 'main' into pdotl-patch-1</li>
<li>Additional commits viewable in <a href="https://github.com/actions/cache/compare/v2...v3">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
ACKs for top commit:
apoelstra:
ACK daa70ea931
tcharding:
ACK daa70ea931
Tree-SHA512: bb832378a7b5cb507a253d263eb55e35bb54f2a738fd379c9022fc30ae81e29f92d5b861ccfae6c1f4bffeb3b72c29bac06cbd374277dcf8e3abd24a362ff459
1f25a40440 Bump model-checking/kani-github-action from 0.15 to 0.36 (dependabot[bot])
Pull request description:
Bumps [model-checking/kani-github-action](https://github.com/model-checking/kani-github-action) from 0.15 to 0.36.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/model-checking/kani-github-action/releases">model-checking/kani-github-action's releases</a>.</em></p>
<blockquote>
<h2>Kani Verifier CI Action 0.36</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.35</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.34</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.33</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.32</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.31</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.30</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.29</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.28</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.27</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.26</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.25</h2>
<p>Bump Kani version to 0.25.0</p>
<h2>Kani Verifier CI Action 0.24</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.23</h2>
<p>Update to Kani 0.23.0</p>
<h2>Kani Verifier CI Action 0.22</h2>
<p>No release notes provided.</p>
<h2>Kani Verifier CI Action 0.21</h2>
<h2>What's Changed</h2>
<ul>
<li>Bump version to 0.21 by <a href="https://github.com/danielsn"><code>@danielsn</code></a> in <a href="https://redirect.github.com/model-checking/kani-github-action/pull/23">model-checking/kani-github-action#23</a></li>
</ul>
<h2>Kani Verifier CI Action 0.20</h2>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="4876903b8a"><code>4876903</code></a> Update Kani version to 0.36.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/47">#47</a>)</li>
<li><a href="402266cd4f"><code>402266c</code></a> Update Kani version to 0.35.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/43">#43</a>)</li>
<li><a href="86cd7a26e0"><code>86cd7a2</code></a> Bump Kani version to 0.34.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/42">#42</a>)</li>
<li><a href="ba46efd09d"><code>ba46efd</code></a> Bump Kani version (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/41">#41</a>)</li>
<li><a href="8b0aa93be2"><code>8b0aa93</code></a> Bump Kani version to 0.32.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/40">#40</a>)</li>
<li><a href="251c15a5fb"><code>251c15a</code></a> update-to-0.31.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/39">#39</a>)</li>
<li><a href="7a843b5dbf"><code>7a843b5</code></a> Bump kani version to 0.30.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/38">#38</a>)</li>
<li><a href="e6805b4b48"><code>e6805b4</code></a> Bump kani version to 0.29.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/37">#37</a>)</li>
<li><a href="15bc38bcae"><code>15bc38b</code></a> Bump Kani version to 0.28.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/36">#36</a>)</li>
<li><a href="9757fc4509"><code>9757fc4</code></a> Update Kani version to 0.27.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/35">#35</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/model-checking/kani-github-action/compare/v0.15...v0.36">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
ACKs for top commit:
apoelstra:
ACK 1f25a40440
tcharding:
ACK 1f25a40440
Tree-SHA512: 38beebebc2402c299d03999096ab0258842e44ebcd11da80e376c41c8ec1ebd8738e15dfcab906af9f094ccf9db763747eaeddd40fd7348d0d3c52d926be9d8d
- 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.
Currently we run the release jobs for all PRs, this leads to red CI runs
any time we have unreleased changes in one crate used by another i.e.,
basically days after a release comes out.
Add a `release.sh` script that has more smarts to try and figure out if
the patch series currently ontop of tip of mater contains changes that
imply its a release PR. To do so we check for changes to the version
field in the manifest of each crate.
99cb83c3e9 ci: do dry-run releases in CI (Andrew Poelstra)
Pull request description:
Will set this to "allow failure" since I think it'll fail during large parts of development, but this will be useful to avoid last-minute problems with releases.
ACKs for top commit:
tcharding:
ACK 99cb83c3e9
Kixunil:
ACK 99cb83c3e9
Tree-SHA512: 32a3e541deba26c0ef3b70a5cf9b4cf8efcebcb962258dd50ff77bd78b38cd9e749246e37133e9ddb806c558faa9cbbc9d8039061cbe888e8abb247c673325a6
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.
Jose Storopoli
Tobin C. Harding
Jamil Lambert, PhD
Andrew Poelstra
dependabot[bot]
Martin Habovstiak
pool2win
Einherjar
Vincenzo Palazzo
Jonathan Underwood