Comments (8)
Thanks for the report!
Sadly this was an oversight on my part when I first released nextest. It would be hard to fix by default in a backwards-compatible manner since there's already likely code in the wild that depends on it. However:
- We can add a config option to store nextest's config in
$CARGO_TARGET_DIR
. - We can fix this if and when we do a breaking change to nextest in the future.
from nextest.
The same problem exists for store.dir
, which defaults to target/nextest
from nextest.
An option to honor target-dir would be great. In some CI environments build.target-dir is used to separate the build and source directory completely. The source tree may for example be located somewhere that is not writable, like a network drive.
So I think it's important to not assume anything about how target-dir relates to the workspace directory.
Another potential solution would be to be able to override "store.dir" to another absolute path in runtime with something like a command line argument.
from nextest.
I don't expect to work on this any time soon but help would be greatly appreciated. At the very least we need to let people set store.dir
to $CARGO_TARGET_DIR/nextest
, which means letting people interpolate $CARGO_TARGET_DIR
if it's at the beginning of the string.
Once that is done, we also need a plan to switch the default. The only place we actually use store.dir
/target/nextest
is in JUnit output. So I think a reasonable way forward would be:
1. Produce a warning
If all of the following are true:
- JUnit output is requested
store.dir
isn't explicitly set and the default value is used- The target dir isn't
source-dir/target
Then, produce a warning saying that the location will be changed in 3 months (let's say we release the warning on 2024-01-01, then we should aim to switch the behavior on 2024-04-01).
In the message, explain how to silence the warning (either set it explicitly to target/nextest
, or opt in by setting it to $CARGO_TARGET_DIR/nextest
).
2. Wait for 3 months
We need to provide sufficient time for people depending on the directory to be notified. 3 months should be enough.
3. Switch the behavior
Switch the default behavior and make a nextest release (I'm happy to do this).
4. Warn for another month
After switching the default behavior, we should keep warning for another time period. Another month or so would be good.
5. Remove the warning
At this point, we've hopefully communicated this to nextest users and they've already switched their workflows.
I'm happy to do the release management, but don't have the time to implement the code. Maybe one of you who have expressed interest can help? @marmeladema @poliorcetics @janderholm
from nextest.
There's a target_directory
field returned by cargo metadata, and a method for this in guppy:
https://docs.rs/guppy/latest/guppy/graph/struct.Workspace.html#method.target_directory
Is there a particular reason for using the environment variable $CARGO_TARGET_DIR
instead of that? I've done a quick test and replacing workspace_root
for that in config_impl.rs
seems to work so it seems fairly easy to implement.
I could simply replace $CARGO_TARGET_DIR
for whatever this variable is set to in store.dir
but I feel that isn't right since it does not have anything to do with the environment variable.
from nextest.
Oh yeah, we should definitely use that field (and do use it in some other places, though it might get remapped with build archive/reuse). Maybe $CARGO_TARGET_DIR/nextest
is not how it should be specified, and instead, something like
[store]
dir = { in-target-dir = true, path = "nextest" }
or similar. I think specifying it as $CARGO_TARGET_DIR/nextest
is okay as well. We don't strictly use the env var as-is but we can communicate this to users.
I think we could go either way on this, I'll let you make a call here.
from nextest.
A thing I did realize is that if the target dir is created by us as part of running tests out of an archive, then the temporary directory will typically be deleted at the end of the run. This is almost certainly not what users want, so in that case I think we should make an exception and keep using <workspace-dir>/target/nextest
just like today. We'll also want to add an info!
message regarding this.
from nextest.
I've listed out a general way we can make behavior changes: https://nexte.st/book/stability.html#making-behavior-changes
from nextest.
Related Issues (20)
- Ability to specify a custom cargo profile? HOT 2
- `build.rs` line change slows tests HOT 2
- Ability to enable features in the configuration HOT 2
- Allow user-specific configuration
- Allow to display stdout, while silencing test harness. HOT 2
- Add support for excluding paths from an archive
- Archive extra files, relative to paths other than the target directory
- Add a way to include extra files on a per-test-binary and per-platform basis
- Add a "testimonials" page (please comment here!) HOT 3
- [windows] lots of tests running in parallel may cause "leaky" warnings HOT 3
- v0.9.70 using significantly more stack HOT 7
- Idea: network isolation between tests HOT 14
- Add support for `cargo test`s --skip and --exact command line flags HOT 1
- `cargo nextest run --workspace` fails with DLL missing if a macro lib exists HOT 14
- nextest chooses arbitrarily not to run some tests it's found HOT 6
- Consider conditions to not include libstd in archives
- [meta] tell users what configuration their tests are running with
- Human-readable configuration output HOT 1
- Machine-readable configuration output
- Feature Request: Conditional skipping test based on setup scripts
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nextest.