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

The workdir for cc_image is not the runfiles directory by default. #2263

Open
mythosliam opened this issue Jul 25, 2023 · 1 comment
Open
Labels
Can Close? Will close in 30 days unless there is a comment indicating why not

Comments

@mythosliam
Copy link

🐞 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:

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

/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 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.

Copy link

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

@github-actions github-actions bot added the Can Close? Will close in 30 days unless there is a comment indicating why not label Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Can Close? Will close in 30 days unless there is a comment indicating why not
Projects
None yet
Development

No branches or pull requests

1 participant