Skip to content
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

Closed
wchargin opened this issue Nov 8, 2020 · 3 comments
Closed

Suggested cache set is insufficient for cargo install #8841

wchargin opened this issue Nov 8, 2020 · 3 comments
Labels
A-documenting-cargo-itself Area: Cargo's documentation C-bug Category: bug

Comments

@wchargin
Copy link

wchargin commented Nov 8, 2020

From the “Cargo Home” docs page (live, source), referring to what
directories should be cached in CI:

It should be sufficient to only cache the following directories across builds:

  • bin/
  • registry/index/
  • registry/cache/
  • git/db/

This doesn’t seem to be sufficient when the job runs cargo install to
install tools, like Cargo subcommands (e.g., cargo-raze). If a job
installs a binary and only caches these directories, a re-run of the job
will fail at cargo install time with

error: binary `cargo-raze` already exists in destination
Add --force to overwrite

because 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)

@wchargin wchargin added the C-bug Category: bug label Nov 8, 2020
@wchargin
Copy link
Author

wchargin commented Nov 8, 2020

@rustbot modify labels: A-documenting-cargo-itself

@rustbot
Copy link
Collaborator

rustbot commented Nov 8, 2020

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.

Please let @rust-lang/release know if you're having trouble with this bot.

@ehuss ehuss added the A-documenting-cargo-itself Area: Cargo's documentation label Nov 30, 2020
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)
@weihanglo
Copy link
Member

This has been fixed by #11592

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-documenting-cargo-itself Area: Cargo's documentation C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

4 participants