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

Needless rebuilds when run with or without --workspace #9114

Closed
ijackson opened this issue Jan 30, 2021 · 5 comments
Closed

Needless rebuilds when run with or without --workspace #9114

ijackson opened this issue Jan 30, 2021 · 5 comments
Labels
C-bug Category: bug

Comments

@ijackson
Copy link
Contributor

Problem

cargo rebuilds things if I switch between cargo build and cargo build --workspace.

Steps

  1. git clone https://salsa.debian.org/iwj/otter
  2. cd otter
  3. git checkout c9b5a88d7a33a6e1eac22736be0a38c6815e1706
  4. cargo build --workspace
  5. cargo build

To repeat, restarting from after step 4 or 5:

  1. touch src/updates.rs
  2. as above
  3. as above

Expected behaviour

The whole workspace including the toplevel package otter was built in step 4, so step 5 should not build anything and should be very quick.

Actual behaviour

cargo rebuilds otter (including library and binaries) in step 5 (about six seconds on my laptop in a repeated test)

Notes

Output of cargo version:

cargo 1.51.0-nightly (783bc43c6 2021-01-20)
@ijackson ijackson added the C-bug Category: bug label Jan 30, 2021
@ijackson
Copy link
Contributor Author

@rustbot modify labels +A-rebuild-detection +A-workspaces

@rustbot
Copy link
Collaborator

rustbot commented Jan 30, 2021

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.

@ijackson
Copy link
Contributor Author

I have been attempting to work around this and the behaviours I'm seeing make me think it may be related to #4463.

@ijackson
Copy link
Contributor Author

A workaround in my environment is to always pass --workspace (plus, usually, suitable -p options) to cargo.

@ehuss
Copy link
Contributor

ehuss commented Jan 31, 2021

Yea, this is expected behavior in that the features chosen depend on which packages are being built. Closing as a duplicate of #4463.

There are other workarounds such as a common package that forces the same features (see rustc-workspace-hack as an example).

@ehuss ehuss closed this as completed Jan 31, 2021
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

3 participants