Hopefully this should automatically publish a GitHub release with
each individual crate's changelog when an appropriate tag is pushed,
provided I haven't made a YAML mistake.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
This PR continues the work started in
https://github.com/tokio-rs/tracing/pull/1646 to replace `chrono` with
`time`. I'll refer to @hawkw's motivation:
> Currently, `tracing-subscriber` supports the `chrono` crate for
> timestamp formatting, via a default-on feature flag. When this code
> was initially added to `tracing-subscriber`, the `time` crate did not
> have support for the timestamp formatting options we needed.
>
> Unfortunately, the `chrono` crate's maintenance status is now in
> question (see #1598). Furthermore, `chrono` depends on version 0.1 of
> the `time` crate, which contains a security vulnerability
> (https://rustsec.org/advisories/RUSTSEC-2020-0071.html). This
> vulnerability is fixed in more recent releases of `time`, but `chrono`
> still uses v0.1.
## Solution
I've replaced chrono with time 0.3. Unfortunately, some of chrono's
builders for DateTimes are not present in `time`, which required the
usage of `macro_rules!` macros to construct some of the hard-coded
times. I also took the opportunity to tidy some of the tests and change
the internal representation of `Rotation::NEVER` from year 9,999 to an
`Option::None`.
This branch changes `tracing-appender`'s MSRV from Rust 1.42 to Rust
1.51, the MSRV for the `time` crate when certain required feature flags
are enabled. This does *not* effect the MSRV for other crates in this
repository.
This branch adds some environment variables to configure *all* CI jobs.
In particular, we:
- disable incremental compilation
- increase the number of retries for network requests in `cargo` and
`rustup`
- emit shortened backtraces from panics
This config was blatantly stolen from linkerd/linkerd2-proxy#7137. :)
Incremental compilation is useful as part of an edit-build-test-edit
cycle, as it lets the compiler avoid recompiling code that hasn't
changed. However, on CI, we're not making small edits; we're almost
always building the entire project from scratch. Thus, incremental
compilation on CI actually introduces *additional* overhead to support
making future builds faster...but no future builds will ever occur in
any given CI environment.
See https://matklad.github.io/2021/09/04/fast-rust-builds.html#ci-workflow
for details.
Increasing retries for network requests should help reduce flakiness a
bit.
## Motivation
Currently, `cargo audit` checks are run on every push that modifies
`Cargo.toml` or lockfiles. The intention behind this was to fail changes
that introduce dependencies that have security advisories. However, it
turns out that this is not actually the primary use-case for `cargo audit`
runs. Typically, when a dependency of a `tracing` crate has a
security advisory, this isn't newly introduced by a PR, but a new
*advisory* that was just announced for a library we *already* depended
on. In this case, this isn't a failure that should block any particular
branch from merging; instead, it's a *new issue* that should block
effected crates from being *released*.
## Solution
This branch changes the audit workflow from running on pushes to running
on a schedule (nightly). When using `actions-rs/audit-check` in a
scheduled mode, it will automatically open new issues if any
dependencies have security advisories (see
https://github.com/actions-rs/audit-check#scheduled-audit for details).
This means those advisories can be fixed separately while still allowing
unrelated branches to pass CI. This is, IMO, a better workflow for
handling security advisories.
If we introduce release automation in the future, we should ensure that
the release automation process checks that the crate being released has
no open security advisory issues, and fails the *release* if any such
issues are still open.
Backports #1648 from `master`.
Depends on #1649
## Motivation
Presently, the `tracing-subscriber` crate requires the Rust standard
library and doesn't build with `#![no_std]` targets. For the most part,
this is fine, as much of `tracing-subscriber` inherently depends on
`std` APIs.
However, `tracing-subscriber` also contains some key abstractions that
are necessary for interoperability: the `Layer` and `LookupSpan`
traits. Since these traits are in `tracing-subscriber`, `no-std` users
cannot currently access them.
Some of the other utilities in this crate, such as the field visitor
combinators, may also be useful for `#![no_std]` projects.
## Solution
This branch adds "std" and "alloc" feature flags to
`tracing-subscriber`, for conditionally enabling `libstd` and
`liballoc`, respectively. The `registry`, `fmt`, `EnvFilter`, and
`reload` APIs all require libstd, and cannot be implemented without it,
but the core `Layer` and `LookupSpan` traits are now available with
`#![no_std]`.
Fixes#999
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
The version of `WithSubscriber` in `tracing::instrument` (rather than in
`tracing-futures`) is currently...useless, since there is no `Future`
impl for the `WithDispatch` type. This means that calling
`with_collector` on a `Future` returns a value that _isn't_ a `Future`.
Additionally, the `WithSubscriber` trait isn't actually implemented for
anything (although this was fixed on v0.1.x).
This branch adds the missing implementations. I also improved the docs a
bit.
Note that the `Future` impl requires the "std" feature flag, but the
`WithSubscriber` trait and `WithDispatch` type do not. This is because
requiring the feature flag for these definitions would *technically* be
a breaking change, since they were previously published without the
feature flag and could e.g. be imported...even though they were totally
useless. Sigh.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
; Conflicts:
; tracing/src/instrument.rs
So...it turns out that passing `--bins` actually makes `cargo check` do
*nothing* on library-only projects without binaries. This
was...surprising.
It turns out that because of this, our MSRV check CI run is basically a
nop, and we accidentally merged code that doesn't compile on 1.42.0. I'm
very dumb lol.
## Motivation
When reviewing https://github.com/tokio-rs/tracing/pull/1523, I
suggested that the examples use `fmt::Layer` directly to allow readers
to copy-and-paste examples into their own code. However, @hawkw pointed
out that rustdoc doesn't receive feature flags from Cargo, which means
that running tracing-subscriber's tests under `--no-default-features`
would fail.
## Solution
It turned out that that we're only running `cargo check
--no-default-features` for tracing-subscriber. Running `cargo test
--no-default-features` resulted in compilation failures, but it seems
like nobody noticed. Building on
https://github.com/tokio-rs/tracing/pull/1532, this branch argues that
running tracing-subscriber's tests under `cargo test --lib --tests
--no-default-features` is _probably_ fine if we're able to skip the
doctests (which are _not_ aware of Cargo's feature flags).
The default behavior for GitHub Actions `matrix` strategies is to cancel
all remaining jobs in a `matrix` job if *any* of them fail. However,
this sometimes obscures important information. For example, we have a
step that runs tests on stable, beta, and nightly Rust. In this case,
it's useful to know whether a failure occurred only on nightly, or if it
effects *every* Rust version.
Furthermore, our branch protection settings don't require the nightly
build to pass in order to merge a PR, because there are sometimes
spurious failures due to nightly-specific bugs. We *do* require the
stable build to pass. However, because the `matrix` strategy will cancel
all jobs in the matrix if any of them fails, this means that we
implicitly *do* require the tests to pass on nightly, as if the nightly
job fails, it will also cancel the required stable job.
This commit updates the github actions config to disable failfast for
some build matrices.
This branch fixes some minor RustDoc issues. In particular:
- The `broken_intra_doc_links` lint was renamed to
`rustdoc::broken_intra_doc_links`. This generates a warning, since the
old name was deprecated.
- `ignore` code blocks are specifically for _Rust_ code that should not
be compiled, not for other text blocks. We were using `ignore` on JSON
blocks, which generates a warning.
- A bunch of links in `tracing-subscriber`'s RustDocs were broken. This
fixes that.
I also changed the Netlify configuration to run with `-D warnings`, so that
we can surface RustDoc warnings in CI builds.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This commit removes the `--tests` from the MSRV build's `cargo check`
invocation. This way, CI will not try to compile dev dependencies on the
MSRV. This is fine, because the tests not building on 1.42.0 won't stop
1.42.0 users from depending on `tracing` crates.
Unfortunately, this means we have to remove the CI job that runs tests
on 1.42.0. But, a significant change in the behavior we're testing for
on our MSRV vs on stable seems unlikely.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Currently, CI runs `cargo check --all --bins --tests --benches` on our
MSRV. This is failing, because the latest `criterion` version now
depends on a revision of `bitflags` that doesn't build on Rust 1.42.0
(due to `const fn`s not being const on 1.42.0).
We *could* solve this by bumping our MSRV to a version where the
appropriate functions are `const fn`, or we could use a `=` dependency
to pin to a specific older version of `bitflags` that compiles on
1.42.0. However, both of these solutions seem kind of unfortunate.
This commit just removes the `--benches` from the MSRV `cargo check`
run. The benchmarks are an internal development tool, not an officially
supported part of `tracing`. Users on 1.42.0 can still depend on
`tracing` and use it in their code even if the benchmarks don't compile
on their (fairly old) Rust version. Therefore, it should be fine to just
remove the benchmarks from the MSRV check.
I split the MSRV and stable `cargo check` jobs into separate jobs, so we
still check that commits don't break the benchmarks on stable Rust.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Tracing's examples depend on a number of external crates that the core
`tracing` crates don't depend on. Sometimes, crates that we only depend
on for examples will break compatibility with our MSRV. It's not ideal
to bump our supported MSRV just for an example, since the actual
`tracing` crates will still build fine.
## Solution
Instead, this PR updates the CI config to exclude examples from the
MSRV check. This way, we don't have to bump MSRV for examples-only
dependencies.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This backports PR #991 to v0.1.x. This is primarily necessary for the MSRV
bump, since some dependencies no longer compile on Rust 1.40.0.
This has already been approved on `master`, in PR #991, so it should be
fine to ship.
## Motivation
This will avoid breaking CI on new releases of clippy. It also makes the
code a little easier to read.
## Solution
- Convert `match val { pat => true, _ => false }` to `matches!(val, pat)`
- Remove unnecessary closures
- Convert `self: &mut Self` to `&mut self`
This bumps the MSRV to 1.42.0 for `matches!`.
The latest version of rust is 1.46.0, so as per
https://github.com/tokio-rs/tracing#supported-rust-versions this is not
considered a breaking change.
I didn't fix the following warning because the fix was not trivial/needed
a decision:
```
warning: you are deriving `Ord` but have implemented `PartialOrd` explicitly
--> tracing-subscriber/src/filter/env/field.rs:16:32
|
16 | #[derive(Debug, Eq, PartialEq, Ord)]
| ^^^
|
= note: `#[warn(clippy::derive_ord_xor_partial_ord)]` on by default
note: `PartialOrd` implemented here
--> tracing-subscriber/src/filter/env/field.rs:98:1
|
98 | / impl PartialOrd for Match {
99 | | fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
100 | | // Ordering for `Match` directives is based first on _whether_ a value
101 | | // is matched or not. This is semantically meaningful --- we would
... |
121 | | }
122 | | }
| |_^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_ord_xor_partial_ord
```
As a side note, this found a bug in clippy 😆https://github.com/rust-lang/rust-clippy/issues/6089
## Motivation
refs #642
Start Testing the core crate in a wasm environment. This requires a
special runner, and an extra dev-dependency.
All tests have been ported over except for
`span::spans_always_go_to_the_subscriber_that_tagged_them_even_across_threads`
because that spins up a thread, and wasm has no concept of threads being
spun up.
## Solution
Add a wasm-pack tester, and properly tag all tests.
refs #642
## Motivation
More, and more code is targeting wasm architectures. This is useful for
not only browsers, but also useful for environments that want
extensibility where the host environment is protected, but still allows
extensibility in a variety of languages. Tracing can help these
architectures just as it can any other architecture.
## Solution
start building all crates, except `tracing-futures` in
wasm32-unknown-unknown architecture. this will validate going forward we
don't break wasm32 build support.
in the future we can start running tests crate by crate, and actually
run those tests. the reason we're doing this is every single test has to
be marked with another special attribute, and add a dev-only dependency.
we don't wanna create a huge pr that has to have conflicts fixed all the
time. in the future we can also look at adding in support for
tracing-futures.
## Motivation
The current MSRV check is lazybones, it's meaningless unless we override
toolchain. Actually, we cannot compile tracing crates with 1.39.0, it
should work with 1.44.0 or later because of the `protobuf` crate and
others.
## Solution
This enforces to override toolchain and updates MSRV to 1.40.0, this
should compile all the crates fine. And replaces
`actions/checkout@master` with `main` as they've renamed the default
branch name to `main`.
It turns out that the test run with `--all-features` should never be
able to pass, due to the `static_max_level` features. Setting
`--all-features` will enable `static_max_level_off`, which disables all
tracing. Therefore, all the integration tests will fail.
However, due to a bug in `tracing`'s `LevelFilter::OFF` implementation,
`static_max_level_off` actually _enables_ everything. This makes the
tests pass accidentally. If we fix this bug, though, everything will be
disabled, as it should be, causing the tests to fail. Therefore, we
can't merge a PR that fixes this, like #853, without first resolving the
issues with the tests.
Unfortunately, these are integration tests, so we cannot just put
```rust
#[cfg(not(any(feature = "static_max_level_off", feature = ...))]
```
on the tests to skip them when the feature is set --- features set on
the _crate_ being tested are not visible to integration tests.
Similarly, we cannot use
```rust
#[cfg(test)]
```
to not set the max level when running the tests, because the test cfg is
not set for the crate when running integration tests, only unit tests.
We could change all these tests to be integration tests, I suppose.
However, we are already running a `cargo hack` job that tests every
feature combination for `tracing` _except_ for the `static_max_level`
ones, so I think it's fine to just remove this.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Adding myself to contributors list so I get tagged on tracing-appender PRs
## Solution
Update CODEOWNERS file
Co-authored-by: Zeki Sherif <zekshi@amazon.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
This branch adds a CODEOWNERS file to configure Github to automatically
assign reviewers for pull requests. In general, when a crate or large
subsystem of a crate was contributed by an individual person, we should
use this file to ensure that that person is assigned to review future
changes to that code.
The @tokio-rs/tracing team should still be tagged to approve all pull
requests, in addition to the person who originally contributed the code,
so the CODEOWNERS file ensures this as well.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Our CI builds currently have an issue where `cargo hack` doesn't work
after loading a cached build of the tool. This causes builds to fail.
See #648.
## Solution
This is an admittedly hacky workaround: I've added a step to check if
`cargo hack` exists by running `cargo hack --help`. If this doesn't
succeed, we assume it doesn't exist and forcibly install it from
crates.io.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, `tracing-futures` and `tracing-attributes` both have separate
crates for tests that require `std::future` and async/await syntax.
These date back to before these features were stable, and the tests were
separated because they could only be run on nighly Rust. This has not
been the case for a long while, and `tracing` now supports `std::future`
as the default, requiring opt-in support for `futures` 0.1. I think we
had forgotten to remove the special-cased tests when we made that
transition.
## Solution
This branch removes the special-cased test crates, and moves all
`std::future` and async/await tests into the main test dirs for these
crates. I've also removed the separate CI steps that ran these.
This should simplify things significantly!
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
I've made some improvements to the CI workflow script.
I've consistently used the `actions-rs` actions where possible and have
enabled caching for several of the jobs, bringing their completion time
from minutes down to seconds. I've also added a job that runs `cargo
audit`.
I added the `.gitattributes` since I was developing on windows. The
rust-lang repo [also uses
this](caa231d998/.gitattributes (L3)).
The `Cargo.lock` needs to be committed (or regenerated on CI if you
prefer; although this will need to be done for each job which is why
I've opted not to do that) in order to generate the hashes for caching
keys. Note that when `Cargo.lock` is updated, the first subsequent CI
run will be slower since the caches need to be repopulated.
Some further improvements would be to cache `~/.rustup` but I'm not sure
the best way to do that here. Options would be to either manually
maintain a lock file used to drive the caching functionality (this is
what I've opted for on my own projects) or alternatively to try and
scrape the currently available versions from some command that fetches
info from upstream.
This adds a fair bit of complexity to the CI script and some of the
choices (committing the lock file for a library) are maybe a bit
controversial so if you'd rather not merge it's okay. Just thought I'd
try to make things a little more efficient!
* Use actions-rs/cargo for problem matchers
* Use actions-rs/toolchain consistently
* Run checkout step before toolchain
* Cache cargo-hack
* Remove unnecessary build steps
* Run cargo-audit
* ci: remove `on: pull_request`
It appears that this setting doesn't actually do what I thought it did.
Having this seems to result in all the CI actions being run one
additional time *when the PR is opened* (which should be identical to
the first push?), and if it fails, it marks the PR as failing
permanently. Subsequent pushes don't appear to change the PR's state.
This is clearly not what we want — I think `on: pull_request` was
intended for stuff like labeling the PR or posting a welcome message for
new contributors, not for running CI jobs.
Therefore, I've removed it.
* make clippy not hate dispatcher doctests
these were copied from the wrong SHA, my bad
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This is a follow up PR for #477 that runs clippy on CI.
* Switch from hecrj/setup-rust-action to actions-rs/toolchain
* Fix remaining clippy lints
* Switch to minimal rustup profile
* Replace warning step with clippy
* Remove #![feature(async_await)]
## Motivation
I've found multiple compilation error involving non-default features.
## Solution
cargo-hack was a suggested solution (by @davidbarsky and @hawkw) to run
compilation checks on all features.
* ci: try cargo-hack
* ci: split cargo-hack execution in multiple jobs
* ci: try splitting checks of tracing-subscriber in dedicated job
Fixes#501
## Motivation
PR #441 increased the minimum supported Rust version, but it only
changed the Azure Pipelines CI configuration, and not the GitHub Actions
one. Additionally, upstream changes to `tower` has broken some of the
examples.
## Solution
This branch bumps the MSRV on GitHub Actions as well, and comments
out examples that depend on code broken upstream.
Additionally, it turns out that — due to Cool Cargo Semver Reasons —
it's more or less impossible to depend on both tokio 0.2.0-alpha.6 *and*
tokio 0.2 release versions. This branch therefore just drops the 0.2.0-alpha.6
support; the next `tracing-futures` will be a breaking change anyway.
Co-authored-by: David Barsky <me@davidbarsky.com>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Because this GitHub Actions workflow requires a secret (for the GitHub
access token), it doesn't work on PRs from external forks of this repo.
Although the labeler action isn't required (and thus doesn't block
merging a PR) it does result a spurious ❌ status on all PRs from
external contributors. This is not great, since new contributors might
get the impression that their CI build is failing and they need to take
actions to fix it, even though this isn't actually the case.
This branch removes the PR labeler action. A low-friction experience for
new contributors is worth more than automatically labeling PRs.
It would be nice if we could figure out a way to get both in the future,
but it's not a high priority.
Closes#360
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
This branch fixes broken builds of `tracing-futures` with the
`tokio-alpha` feature.
## Solution
I've added the missing `WithDispatch` impl for
`std::future::Future` that was breaking the build. I've also
updated the `tokio` alpha dependency, and added a CI check
that the tokio-alpha feature flag compiles.
Fixes#337
* futures: add missing `WithDispatch` impl
* futures: update tokio alphas
* chore: add CI job to ensure tokio alpha compiles
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Apparently, the GitHub Actions `paths:` filtering for events uses [an
API][1] from the standard library of a known bad programming language,
which [doesn't behave the way normal unix globs do][2] and [cannot match
arbitrarily nested files][3].
This means that the filter was running the CI action only on PRs that
changed a `Cargo.toml` or `*.rs` _in the root of the repository_, rather
than _any_ `Cargo.toml` or `*.rs`, as a reasonable person might assume
it would.
## Solution
This branch removes path filtering from the CI workflow, since
apparently it is *impossible* to get the relatively simple behavior we
would want using this thing.
Since almost all `tracing` pull requests touch a `*.rs` or `Cargo.toml`
anyway, this path filtering wasn't really getting us a whole lot.
Removing it shouldn't make a huge difference. It's a shame that we have
to do a full Rust build & test run on PRs that only touch READMEs etc,
but \_(ツ)_/¯.
[1]: https://help.github.com/en/articles/workflow-syntax-for-github-actions#onpushpull_requestpaths
[2]: https://golang.org/pkg/path/#Match
[3]: https://github.com/golang/go/issues/11862
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The `tokio` org is in the Github actions beta. Running our CI jobs on Actions
rather than Azure Pipelines has a few potential advantages:
- GitHub Actions allows us to conditionally run workflows based on what
files were modified. This lets us configure the Rust CI tests/checks
to only run when actual Rust source code was modified. This will let
us merge PRs that change READMEs, CI configs, etc. but don't actually
modify any source code more quickly, since they won't have to wait
for all the tests to run.
- GitHub Actions has slightly nicer integration with the GitHub UI
(IMO), and it takes fewer clicks to see the logs from a failed build
than on Azure.
- Finally, I've (anecdotally) observed GitHub Actions workflows to
start much sooner than the corresponding Azure Pipelines workflows.
Although the stages seem to take similar amounts of time to run, it
seems like there's sometimes a delay between an event that triggers
Azure Pipelines and the job actually starting. My guess is that
GitHub Actions recieves the triggering webhook a bit sooner because
it's running on the same infrastructure that actually hosts the repo?
## Solution
This branch ports the Azure Pipelines CI configs to run on GitHub
Actions. I've tried to port the config relatively faithfully, with a
few tweaks.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, we link to RustDoc on docs.rs. This is built when a crate is
published to crates.io. In some cases, it is also valuable to publish
the documentation for the latest `master` branch, so that users using
git dependencies can see up to date docs.
## Solution
This branch adds a GitHub action that will build docs & publish them to
the `gh-pages` branch when source files change.
Closes: #210
* add pages publish action on master commits
* only rebuild when sources change
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
The `tokio` org is now part of the github actions beta.
This branch dips our feet in the metaphorical water by
setting up a simple action that adds crate labels to PRs.
* chore: add PR labeler action
* add PR labeler config
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch removes all remaining references to the
non-existent `tracing-nursery` repository that weren't
removed in #142 and #141.
Closes#125
* chore: remove nursery mentions from .github
* core: remove references to `tracing-nursery`
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
See #95
This branch renames everything from `tokio-trace` to `tracing`.
Unlike PR #98, the nursery crates still depend on the crates.io
versions of `tokio-trace` and `tokio-trace-core`, but renamed
to `tracing`/`tracing-core` in `Cargo.toml`. We can update the
nursery crates to depend on local path dependencies in a
subsequent PR, as that will require making code changes to the
nursery crates.
This branch _also_ updates the minimum Rust version to 1.34.0,
to the shock and horror of the millions of `tracing` users still
on Rust 1.26.0. This was necessary in order to allow renaming
crates in `Cargo.toml`, and to resolve that not using the `dyn`
keyword is now a warning on nightly.
Closes#98Closes#95
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch adds a `README.md`, a `CONTRIBUTING.md`, and issue and pull
request templates. These are all based on `tokio-rs/tokio`'s, with some
minor tweaks.
Fixes: #7
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
