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

Tests are only run on workspace default package #186

Open
detly opened this issue Apr 23, 2024 · 3 comments
Open

Tests are only run on workspace default package #186

detly opened this issue Apr 23, 2024 · 3 comments

Comments

@detly
Copy link

detly commented Apr 23, 2024

See the test project here. It's a simple workspace project with a member package member-one. The member-one package has an error in a unit test, so it builds when cargo build --workspace or cargo test are run from the root, but fails when cargo test --workspace is run from the root.

If I run bacon in the root directory, it builds the whole workspace by default. If you create an error in member-one in the non-test code, it's shown. If you remove it, it all passes.

If I then press t, Bacon still shows the project as passing, even though using cargo test --workspace directly fails. It seems like Bacon is doing a whole-workspace build, but not testing the whole workspace.

Versions:

  • bacon: 2.16.0
  • rustc: 1.77.0
  • cargo: 1.77.0
  • OS: Ubuntu 23.10

Rust toolchain installed via Rustup, default is stable. Bacon installed via Cargo.

@jwilger
Copy link

jwilger commented Dec 12, 2024

Just update your config so that it includes:

[jobs.test]
command = ["cargo", "test", "--workspace"]

@detly
Copy link
Author

detly commented Dec 15, 2024

@jwilger it's the inconsistency of it that's really the crux of the issue:

  • if the default package is in the state "fails to build", there's a visible error
  • fixing the build error but leaving a test failure (state = "tests failing") results in the test failure becoming apparent
  • fixing the test failure results in no visible errors (state = "all good")

But

  • in the state "member package fails to build", there's a visible error
  • fixing the build error but leaving a test failure results in no visible errors, so it seems like state = "all good" because that's what the other scenario does, when actually state = "tests failing"

@jwilger
Copy link

jwilger commented Dec 15, 2024

Ah, ok. I didn't realize that was the case. Good to know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants