Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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!

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

No branches or pull requests

2 participants