267a53a9e8
* test: use dedicated ports for CLI tests * chore: update `tracing-subscriber` * fix: work around tracing-subscriber weirdness It seems that trogging with tracing-subscriber >= 0.3.14 does not produce any output at all. I suspect we are hitting <https://github.com/tokio-rs/tracing/issues/2265>. Let's change the construct to not use multiple optional layers but a single dyn-dispatch layer. Logging shouldn't have such a high throughput that his makes any difference, esp. because the dyn-dispatch happens AFTER the filter. |
||
|---|---|---|
| .. | ||
| src | ||
| .gitattributes | ||
| Cargo.toml | ||
| README.md | ||
| build.rs | ||
README.md
workspace-hack
This crate is a "workspace hack" crate managed by cargo hakari.
Its purpose is to unify the features used by all crates in the workspace so that the crates share more dependencies and rebuild crates less. There are more details in hakari's documentation.
CI failures
If the workspace_hack_checks CI job is failing, there are two possible reasons and solutions:
- If
cargo hakari generate --difffails, that means a crate has started or stopped using a feature of some crate and that feature isn't up-to-date in theworkspace-hackcrate. To fix this, runcargo hakari generateand commit the changes. - If
cargo hakari manage-deps --dry-runfails, that means a crate in the workspace isn't depending on theworkspace-hackcrate. To fix this, runcargo hakari manage-depsand commit the changes.