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
6b3c8b9f6b ci: use personal access token for daily nightly update (Andrew Poelstra)
775d0c74cd ci: change automatic CI bot committer name to something without special characters (Andrew Poelstra)
aa8655552b ci: change branch of nightly bot to not conflict with rustfmt bot (Andrew Poelstra)
Pull request description:
Rename the bot's committer name to not have special characters, which causes some problem in tcharding's locale; also change the branch name to not overlap with the "weekly CI" job, since it's causing the two jobs to overwrite each others' PRs.
Was part of #2531 but pulled out here to be in a branch that isn't getting clobbered every 24 hours :).
ACKs for top commit:
tcharding:
ACK 6b3c8b9f6b
Tree-SHA512: 2e605991132eb36543d8fb2636bc70c7cc834db6078d2cc6242c65c0f8c5fd270fc9881e6a5c28f5d87a03551fa4f1e0ad3e87c86c226db5e5b8a4c21270ef8c
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.)
These are not run in CI since #2353 and are likely to go out of date. If
we want a script that users can run locally then we should create a new
script that wraps our current CI.
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.
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))]
```
Tobin C. Harding
Andrew Poelstra
Update Nightly Rustc Bot
dependabot[bot]
Martin Habovstiak
pool2win
Einherjar
Vincenzo Palazzo
Jonathan Underwood