The second invocation would always fail, since that version had already
been published. This command failing would cause the script to exit with
an error, and thus fail to push the release tag.
This commit fixes this by removing the second `cargo publish`.
* fix use of `cargo --list` in bin/publish
* fix shellcheck lints in bin/publish
* set -euo pipefail
* fix cargo hack exit status check
* fix wrong emptystring args
* prompt before installing cargo-hack
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The `tracing`' crate's feature powerset is kind of unmanageably huge due
to the large number of `max_level_XXX` and `release_max_level_XXX`
feature flags. This is why we currently _don't_ run a `cargo-hack`
feature powerset check for it on CI. However, I forgot about that when I
added feature powerset checks to the `bin/publish` script, so publishing
a `tracing` release results in a combinatorial explosion that takes a
*very* long time to complete.
## Solution
It turns out that `cargo-hack` actually has flags for controlling what
features are included in the powerset (`--include-features` and
`--exclude-features`). This branch modifies `bin/publish` to use those
flags when checking the `tracing` and `tracing-subscriber` crate.
Additionally, I've modified the CI `cargo-hack` job to use the same
flags, so that it can now check `tracing` and `tracing-subscriber`.
This allows us to remove the manual feature check jobs for those crates
from CI.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This adds a check to the `bin/publish` script that the crate being
published builds successfully with all possible feature combinations,
using `cargo hack --feature-powerset`.
This would have prevented https://github.com/tokio-rs/tracing/issues/1944.
We test this on CI for most crates in the repo, but it's disabled for some
crates because the powerset is very large, making the check too slow
to run on CI. However, adding it to the publish script will ensure that it's
at least always run before publishing a crate.
## Motivation
Intra-workspace dependencies can go out of sync if only referencing
crates.io, where changing one crate locally and testing the whole
library will result in errors stemming from two different versions of
the same trait etc. This is hard to keep track of and makes development
more difficult than it needs to be.
## Solution
Afaik it's common practice to specify both a version and a path as per
[the cargo docs][1]. This is what tokio does with its subcrates too.
[1]: https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/specifying-dependencies.md#multiple-locations.
This branch updates CONTRIBUTING.md to document how to release
a new version of a Tracing crate, and adds the `publish` shell script
from the `tokio-rs/tokio` repo to aid in the release process.
I've also updated references in CONTRIBUTING.md to refer to Tracing
rather than Tokio Trace.
* docs: add release section to CONTRIBUTING.md
* add publish script
* docs: remove references to tokio-trace/nursery
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
