This PR tweaks the installation of `cargo-semver-checks` to make it use the `--locked` flag.
Installing binaries with their locked dependency versions makes it less likely that you might run into issues caused by bugs in dependency libraries, since your installed dependency versions match the versions used in the binary's own test environment.
This is a recommendation that applies to most Rust binary tools. For example, here's cargo-nextest recommending the same: https://nexte.st/book/installing-from-source.html#installing-from-cratesio
We refactor our continuous integration workflow with the following goals in mind:
- Run as few jobs as possible
- Have the jobs finish as fast as possible
- Have the jobs redo as little work as possible
There are only so many jobs that GitHub Actions will run in parallel.
Thus, it makes sense to not create massive matrices but instead group
things together meaningfully.
The new `test` job will:
- Run once for each crate
- Ensure that the crate compiles on its specified MSRV
- Ensure that the tests pass
- Ensure that there are no semver violations
This is an improvement to before because we are running all of these
in parallel which speeds up execution and highlights more errors at
once. Previously, tests run later in the pipeline would not get run
at all until you make sure the "first" one passes.
We also previously did not verify the MSRV of each crate, making the
setting in the `Cargo.toml` rather pointless.
The new `cross` job supersedes the existing `wasm` job.
This is an improvement because we now also compile the crate for
windows and MacOS. Something that wasn't checked before.
We assume that checking MSRV and the tests under Linux is good enough.
Hence, this job only checks for compile-errors.
The new `feature_matrix` ensures we compile correctly with certain feature combinations.
`libp2p` exposes a fair few feature-flags. Some of the combinations
are worth checking independently. For the moment, this concerns only
the executor related transports together with the executor flags but
this list can easily be extended.
The new `clippy` job runs for `stable` and `beta` rust.
Clippy gets continuously extended with new lints. Up until now, we would only
learn about those as soon as a new version of Rust is released and CI would
run the new lints. This leads to unrelated failures in CI. Running clippy on with `beta`
Rust gives us a heads-up of 6 weeks before these lints land on stable.
Fixes#2951.
Remove default features. You need to enable required features
explicitly now. As a quick workaround, you may want to use the
new `full` feature which activates all features.
Adds two workflows on push & PR:
* `run-ping-interop-cross-version`: runs a Testground interoperability test
between multiple versions of rust-libp2p, including master, and the current
branch (during a pull request)
* `run-ping-interop-cross-implementation`: runs a Testground interoperability
test between go-libp2p and rust-libp2p, and the current branch (during a pull
request)
We rely on the https://github.com/libp2p/test-plans/ repository to retrieve and
run the tests.
Co-authored-by: Piotr Galar <piotr.galar@gmail.com>
* build(deps): Update prost-build requirement from 0.9 to 0.10
Updates the requirements on [prost-build](https://github.com/tokio-rs/prost) to permit the latest version.
- [Release notes](https://github.com/tokio-rs/prost/releases)
- [Commits](https://github.com/tokio-rs/prost/commits)
---
updated-dependencies:
- dependency-name: prost-build
dependency-type: direct:production
...
Signed-off-by: dependabot[bot] <support@github.com>
* .github/workflow: Don't run integration test in container
* .github/workflow: Don't run doc step in container
* .github/workflows: Remove component docs
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
`prost-build` is failing due to a missing `protoc` binary. Neither the OS
supplies one, nor can the bundled binaries be used. This commit downgrades the
OS used. The older OS is compatible with the bundled `protoc` binaries.
Changes needed to get libp2p to run via `wasm32-unknown-unknown` in the browser
(both main thread and inside web workers).
Replaces wasm-timer with futures-timer and instant.
Co-authored-by: Oliver Wangler <oliver@wngr.de>
To have caches operate at its maximum usefulness, we need to have a
1-to-1 mapping between build-comamnd and cache key. Otherwise rustc
has to rebuild certain artifacts because they were not in the cache.
By using matrices, we make github parallelise some of our jobs. This
has a double positive impact on CI runtime. Not only are our caches
more effective now, several jobs are now run in parallel.
Co-authored-by: Max Inden <mail@max-inden.de>
With `rand` `v0.8.0` platform support changed [1] due to its upgrade to
`getrandom` `v0.2`. With `getrandom` `v0.2` `wasm32-unknown-unknown` is no
longer supported out of the box:
> This crate fully supports the wasm32-wasi and wasm32-unknown-emscripten
> targets. However, the wasm32-unknown-unknown target is not automatically
> supported since, from the target name alone, we cannot deduce which JavaScript
> interface is in use (or if JavaScript is available at all).
>
> Instead, if the "js" Cargo feature is enabled, this crate will assume that you
> are building for an environment containing JavaScript, and will call the
> appropriate methods. Both web browser (main window and Web Workers) and
> Node.js environments are supported, invoking the methods described above using
> the wasm-bindgen toolchain.
>
> This feature has no effect on targets other than wasm32-unknown-unknown.
This commit drops support for wasm32-unknown-unknown in favor of the two more
specific targets wasm32-wasi and wasm32-unknown-emscripten.
Note on `resolver = "2"`: The new resolver is required to prevent features
being mixed, more specifically to prevent libp2p-noise to build with the
`ring-resolver` feature. See [3] for details.
---
[1] https://github.com/rust-random/rand/blob/master/CHANGELOG.md#platform-support
[2] https://docs.rs/getrandom/0.2.2/getrandom/#webassembly-support
[3] https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2
Instead of fully executing benchmarks, i.e. running multiple iterations,
each measured and recorded, only test that they compile and run them
with a single execution to make sure they work. The benefit is a reduced
CI runtime.
Flag documentation:
> To test that the benchmarks run successfully without performing the
measurement or analysis (eg. in a CI setting), use cargo test --benches.
https://bheisler.github.io/criterion.rs/book/user_guide/command_line_options.html
The above assumes that (a) the benchmark results from CI are likely
noisy and thus (b) no one actually looks at the benchmark results.
* Make clippy "happy".
Address all clippy complaints that are not purely stylistic (or even
have corner cases with false positives). Ignore all "style" and "pedantic" lints.
* Fix tests.
* Undo unnecessary API change.
* core: Add rudimentary benchmark for PeerId::from_bytes and clone
* .github/workflow: Include benchmarks
To ensure changes through pull requests won't make benchmarks fail to
compile or run, run them as part of CI.
