-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggested cache set is insufficient for cargo install
#8841
Labels
Comments
@rustbot modify labels: A-documenting-cargo-itself |
Error: The feature Please let |
bors
added a commit
that referenced
this issue
Dec 18, 2022
Enable triagebot's relabel functionality ### What does this PR try to resolve? This fixes the following failure that rustbot currently posts whenever someone tries to use "<b>`@</b><b>rustbot</b>` label" in this repository. > **Error**: The feature `relabel` is not enabled in this repository. > To enable it add its section in the `triagebot.toml` in the root of the repository. Unauthenticated relabel has been enabled in rust-lang/rust for nearly 4 years. People overwhelmingly use it in good faith. <br> ### How should we test and review this PR? Compare against https://github.com/rust-lang/rust/blob/1.66.0/triagebot.toml. Also skim through the 7 pages of labels on https://github.com/rust-lang/cargo/labels, whether it makes sense the ones I decided to allow arbitrary GitHub users to apply. <br> ### Additional information Attempted uses of "<b>`@</b><b>rustbot</b>` label", that failed, but this PR would allow: - #10343 (comment) - #10243 (comment) - #9982 (comment) - #9128 (comment) - #9067 (comment) - #8441 (comment) - #11432 (comment) - #8841 (comment) - #10820 (comment) - #10572 (comment) - #9114 (comment) - #8980 (comment) - #9064 (comment) - #8726 (comment) - #8089 (comment)
This has been fixed by #11592 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From the “Cargo Home” docs page (live, source), referring to what
directories should be cached in CI:
This doesn’t seem to be sufficient when the job runs
cargo install
toinstall tools, like Cargo subcommands (e.g.,
cargo-raze
). If a jobinstalls a binary and only caches these directories, a re-run of the job
will fail at
cargo install
time withbecause the binary exists but Cargo has no record that it has been
installed. Sample failure:
https://github.com/tensorflow/tensorboard/runs/1367174061
It sufficed for me to also cache
.crates.toml
and.crates2.json
.Maybe only the former is needed; I included the latter to be safe.
Especially since these are dotfiles, it would be nice to document that
they, too, should be cached.
I would submit a patch, but I don’t know exactly what the right
recommendation is.
cargo version 1.47.0 on Linux (Debian/Ubuntu)
The text was updated successfully, but these errors were encountered: