Closed jcpetruzza closed 4 years ago
As a workaround, you can probably set STACK_ROOT
to override the location of ~/.stack
. I think this should be forwarded inside the repository rule calling stack
@regnat Setting STACK_ROOT
does seem to work, thanks! I was somehow expecting it to be ignored...
Describe the bug We are seeing build failures on CI, with an error message that looks as follows:
It turns out this happens when two CI jobs are running simultaneously on the same box and it is likely due to
stack ls dependencies
not protecting certain operations with a lock.Even though there is probably a bug in
stack
here, the fact that all bazel workspaces depend on artifacts under~/.stack
make isolation and even hermeticity arguably harder to enforce. Would it make sense to runstack
with--stack-root
pointing to a directory controlled by thestack_snapshot()
rule?To Reproduce I managed to reproduce the error locally by doing the following:
rm -Rf ~/.stack/
bazel clean --expunge; bazel build //...
I imagine that a relatively large number of stackage dependencies may be needed for the race condition to manifest.
Expected behavior Concurrent builds don't interfere with each other.
Environment
bazel-1.1.0
andstack-2.1.3.1
, both provisioned fromnixpkgs
master
(c169112800280cdc87964e9cad1752f643b603dd
)Additional context
At the moment we don't have a workaround for this, ideas are welcome!