## 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>
