You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 2, 2023. It is now read-only.
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:
workspace(name = "awesome")
and I have the following cc_image located in my repository at `src/apps/:
cc_image(
name = "my_fun_cc_image",
base = "@ubuntu_base//image",
binary = ":my_fun_cc_binary",
)
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
which works if I just run the cc_binary with bazel run but will not work (the file can't be found) when I run the cc_image because of the incorrect working directory.
🌍 Your Environment
Operating System:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focal
Output of bazel version:
$ bazel version
Build label: 6.0.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Dec 19 15:52:35 2022 (1671465155)
Build timestamp: 1671465155
Build timestamp as int: 1671465155
Rules_docker version:
v0.25.0
Anything else relevant?
I'm currently working around this by wrapping my cc_image rule in a container_image rule where I manually set the workdir to the expected runfile directory e.g.
cc_image(
name = "__my_fun_cc_image",
base = "@ubuntu_base//image",
binary = ":my_fun_cc_binary",
)
container_image(
name = "my_fun_cc_image",
base = "__my_fun_cc_image",
workdir = "/app/src/apps/my_fun_cc_binary.runfiles/",
)
which works (i.e. data deps can be loaded as they are when bazel runing the cc_binary) but this seems hacky/incorrect.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
🐞 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: