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

Bug: default store directory does not respect CARGO_TARGET_DIR #2066

Open
tgross35 opened this issue Jan 14, 2025 · 6 comments
Open

Bug: default store directory does not respect CARGO_TARGET_DIR #2066

tgross35 opened this issue Jan 14, 2025 · 6 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@tgross35
Copy link

Description of the issue

Description:

Nextest always tries to create the store directory at the workspace root, which fails if the workspace is read-only.

Steps to reproduce:

  1. Go to any existing project, ensure the target directory is clean (or at least target/nextest does not exist)
  2. Launch a Docker container that mounts the current workspace as read only, and sets CARGO_TARGET_DIR. : docker run --rm -e CARGO_TARGET_DIR=/target -v "$(pwd):/checkout:ro" -it rust bash
  3. Install nextest: cargo install cargo-nextest
  4. cd /checkout
  5. Try running tests normally: cargo test. This should work
  6. Try running tests via nextest: cargo nextest run. This fails with something like:
error: failed to create store dir at `/checkout/target/nextest/default`

Caused by:
  Read-only file system (os error 30)

Expected outcome

By default, rather than using a path relative to the workspace root, nextest should create its store directory within CARGO_TARGET_DIR if it is set.

Actual result

Unable to create the file (see above)

Nextest version

cargo-nextest 0.9.87 (fee71ad7b 2024-12-17)
release: 0.9.87
commit-hash: fee71ad7ba08be06519cf9eeb495c6fce0a2e888
commit-date: 2024-12-17
host: aarch64-unknown-linux-gnu

Additional context

No response

@tgross35 tgross35 added the bug Something isn't working label Jan 14, 2025
@sunshowers
Copy link
Member

Thanks -- yeah, this has been a problem for a while. I'd definitely like to change the default at some point, but that would have to be a carefully-managed behavior change. I think for now we should let you set the target directory to be the same as CARGO_TARGET_DIR.

@tgross35
Copy link
Author

Would some form of environment interpolation in config be possible? Maybe the default could change to be store.dir = "${CARGO_TARGET_DIR:-target}/nextest" which would probably be correct in most cases.

@sunshowers
Copy link
Member

Yeah -- though in this other case we decided to let you say relative-to = "target", which we should probably be consistent with.

https://nexte.st/docs/ci-features/archiving/#adding-extra-files-to-an-archive

So you'd say

store.dir = { path = "nextest", relative-to = "target" }

and we'd eventually make this the default.

@pantos9000
Copy link

I have a build container that mounts the root dir and writes all of its output to the folder target_builder by setting CARGO_TARGET_DIR. At the same time, it is possible to build locally with default settings (i.e. using target as target dir) - even in parallel - because the target folders don't conflict.

There are occasions where it is quite useful to be able to do that, so it would be nice if the store.dir setting would respect the environment variable.

To work around that, I use a wrapping bash script that checks for CARGO_TARGET_DIR and calls nextest with the according config file, but that is quite ugly.

@sunshowers
Copy link
Member

Absolutely agreed that this is an issue -- please submit a PR!

@sunshowers sunshowers added the help wanted Extra attention is needed label Feb 12, 2025
@sunshowers
Copy link
Member

I've started on this in #2154. I would love somebody's help completing this (in particular, writing tests for this). I'm also not sure how temporary target directories should be handled, and would appreciate ideas there as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants