We also need to prepend the `clippy::allow` with an `unknown_lints` lint because clippy 1.71 does not (yet) know about this new lint.
Pull-Request: #4219.
We receive a lot of PRs from dependabot for version updates to our lockfile and Cargo.toml. Whilst it is nice that those are explicit, they require quite some work from maintainers. Often, these PRs only get queued to be merged when a maintainer is next active on a repository which is also likely at a time they want to merge other PRs.
We don't want to automatically merge all updates that are coming in because they might be breaking changes for us if they are exposed in our public API. We solve this by only merging updates that are in a semver-compatible range:
- For major >= 1 updates, only approve them if they have the same major version.
- For major == 0 updates, only approve them if they have the same minor version.
We also add a rule to automatically queue PRs from dependabot with an approval. This avoids us having to approve AND apply the `send-it` label.
Resolves#4186.
Pull-Request: #4210.
I'm not able to build this container on my machine arm64 linux because the builder is missing the `wasm-opt` binary. I'm not sure why CI manages to do so. I'm guessing the x86 image is slightly different and may include `wasm-opt`.
This makes a change to that dockerfile to explicitly install `wasm-opt`.
Here's the previous error:
```
// ...
#0 36.90 Finished release [optimized] target(s) in 35.97s
#0 36.91 Installing /root/.cache/.wasm-pack/.wasm-bindgen-cargo-install-0.2.87/bin/wasm-bindgen
#0 36.91 Installing /root/.cache/.wasm-pack/.wasm-bindgen-cargo-install-0.2.87/bin/wasm-bindgen-test-runner
#0 36.91 Installing /root/.cache/.wasm-pack/.wasm-bindgen-cargo-install-0.2.87/bin/wasm2es6js
#0 36.91 Installed package `wasm-bindgen-cli v0.2.87` (executables `wasm-bindgen`, `wasm-bindgen-test-runner`, `wasm2es6js`)
#0 37.06 warning: be sure to add `/root/.cache/.wasm-pack/.wasm-bindgen-cargo-install-0.2.87/bin` to your PATH to be able to run the installed binaries
#0 37.22 Error: no prebuilt wasm-opt binaries are available for this platform: Unrecognized target!
#0 37.22 To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.
#0 37.22 Caused by: no prebuilt wasm-opt binaries are available for this platform: Unrecognized target!
#0 37.22 To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.
------
ERROR: failed to solve: executor failed running [/bin/sh -c wasm-pack build --target web interop-tests]: exit code: 1
```
Another solution would be to diable wasm-opt as mentioned in the error message as well.
Pull-Request: #4192.
With the move to running our CI on self-hosted runners, this job tends to always be the slowest one. We move it to a bigger runner such that it finishes closer to all the other jobs.
Pull-Request: #3861.
- Fixes typo in `<OrTransport as Transport>::listen_on` using the word "dial" instead of "listen_on".
- Adds logging to `<OrTransport as Transport>::dial`.
Follow-up to https://github.com/libp2p/rust-libp2p/pull/4133
Pull-Request: #4164.
Currently, when trying addresses in `listen_on` via `OrTransport`, there are no logs to facilitate debugging. This PR corrects that by providing adequate logs via `std::any::type_name` method.
Resolves#4072.
Pull-Request: #4133.
The current implementation in Kademlia relies on an external address to determine if it should be in client or server mode. However there are instances where a node, which may know an external address, wishes to remain in client mode and switch to server mode at a later point.
This PR introduces `Kademlia::set_mode`, which accepts an `Option<Mode>` that would allow one to set `Mode::Client` for client mode, `Mode::Server` for server mode, or `None` to determine if we should operate as a client or server based on our external addresses.
Resolves#4074.
Pull-Request: #4132.
Unfortunately, the automated contribution message does not work properly. To evaluate this correctly, we need to first filter out all merge commits. To do this, we need to check the length of the `parents` property. I did not find a way to do this with jinja2 filters. Which would allow us to do something like `rejectattr`.
In the code snippet removed in this PR, I attempted to create a property to filter the merge commits on. This also doesn't work because the underlying object exposed by mergify is not a dictionary but a class and thus does not have the `update` function.
Mergify is shipping an additional property next month: https://github.com/Mergifyio/mergify/discussions/4636#discussioncomment-6295474. Thus, I am replacing this automated mechanism with a manual section that we can add to the PR until mergify ships the additional property that we can utilize to implement this in a clean way.
Related: #4130.
Related: #4104.
Pull-Request: #4131.
