The workdir
for cc_image
is not the runfiles directory by default.
#2263
Labels
Can Close?
Will close in 30 days unless there is a comment indicating why not
🐞 bug report
Affected Rule
This seems to affect at least
cc_image
.Is this a regression?
Not that I am aware of.
Description
When building and running a
cc_image
, the working directory for the entrypoint is not the runfiles directory by default. Instead, it is the runfiles directory + the repository name appended to the end.For example if my repository has the following workspace name in
WORKSPACE
:and I have the following
cc_image
located in my repository at `src/apps/:I would expect the working directory used by the entrypoint to be:
/app/src/apps/my_fun_cc_binary.runfiles/
Instead it is
/app/src/apps/my_fun_cc_binary.runfiles/awesome/
This causes problems when
my_fun_cc_binary
has any data dependencies since they are placed relative to the runfile directory e.g. if my app tries to load/app/src/apps/my_fun_cc_binary.runfiles/awesome/src/data/some_data_dep.csv
it would reference it in code with
./awesome/src/data/some_data_dep.csv
which works if I just run the
cc_binary
withbazel run
but will not work (the file can't be found) when I run thecc_image
because of the incorrect working directory.🌍 Your Environment
Operating System:
Output of
bazel version
:Rules_docker version:
Anything else relevant?
I'm currently working around this by wrapping my
cc_image
rule in acontainer_image
rule where I manually set theworkdir
to the expected runfile directory e.g.which works (i.e. data deps can be loaded as they are when
bazel run
ing thecc_binary
) but this seems hacky/incorrect.The text was updated successfully, but these errors were encountered: