Open guibou opened 5 years ago
I have no clear vision as to how to fix this. The only idea I have is adding select
to the deps
, which would make deps
empty if the worker flag is not passed. I might have time to try it out later in the week.
The issue seems to be that bazel fetch
does not take configuration into account (same as bazel query
). A similar issue is discussed in rules_go here.
As a possible workaround, depending on the use-case, both bazel fetch
and bazel query
accept a --keep_going
flag to ignore such errors. Of course that also hides legitimate errors.
To avoid this error we may have to avoid using select
.
Is there an upstream ticket about this in https://github.com/bazelbuild/bazel? @ianthehat mentions that some kind of "no execute" flag might get added to bazel build
, but I'm not sure whether that has happened in the intervening two years, or whether there are still plans to do so in the future.
@mboes Yes, https://github.com/bazelbuild/bazel/issues/8565 describes the issue that bazel fetch
does not take configuration into account. They propose bazel sync
as an alternative, @guibou would bazel sync
work for your use-case?
Related, https://github.com/bazelbuild/bazel/issues/3246 describes that bazel fetch
does not fetch all registered toolchains. Maybe we could work around this issue that way, define a new toolchain for the worker, in non-worker mode it resolves to a dummy toolchain, and in worker mode it resolves to a toolchain that contains the proper worker.
@guibou any word on the question above?
@guibou any thoughts?
bazel sync
fetchs a lot too much and it seems to refetch everything unconditionally, but does not fail.
I've removed bazel fetch
from my workflow, so this is not an issue anymore for me.
I guess we can close then? Feel free to reopen.
NOTE: some instances of bazel query
may also triggers this behavior. For example: bazel query 'kind(".*haskell_library", allpaths(//..., //...)
.
We are running into this issue too. Something as basic as this query will trigger the error:
bazel query 'deps(//some/haskell/binary')'
@guibou's workaround worked for us, but still this issue should probably be reopened.
FYI the build --nobuild
mode made available in https://github.com/NixOS/nixpkgs/commit/d7d4a926957de29e8e618d1c848e2036ea98d9cc seems to address shortcomings of fetch
.
Describe the bug
On a client codebase
bazel fetch //...
fails with:Note that we are not using the new worker feature.
This is solved by adding the following at the end of our
WORKSPACE
and providingstack
in your build environment:To Reproduce
bazel fetch //...
in a bazel workspace which does not callrules_haskell_worker_dependencies
.Expected behavior
rules_haskell_worker_dependencies
call should not be mandatory if the feature is not usedstack
should not be mandatory if stack features are not used.