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

Files added to runfiles are not visible with BwtB #20099

Closed
gergelyfabian opened this issue Nov 8, 2023 · 3 comments
Closed

Files added to runfiles are not visible with BwtB #20099

gergelyfabian opened this issue Nov 8, 2023 · 3 comments
Labels
team-Remote-Exec Issues and PRs for the Execution (Remote) team type: bug untriaged

Comments

@gergelyfabian
Copy link

gergelyfabian commented Nov 8, 2023

Description of the bug:

I have an example repo with rules_scala:

https://github.com/gergelyfabian/bazel-scala-example/ (check out bazel-7.0.0rc2 branch)

If I run a target to check scalafmt there, it will fail with BwtB (please note, that disk cache is turned on in this repo):

$ bazel run //example-maven:example-maven.format-test
...
diff: /home/user/.cache/bazel/_bazel_user/64527517dacf7170f7d914889f83481c/execroot/_main/bazel-out/k8-fastbuild/bin/example-maven/example-maven/src/main/scala/mypackage/Maven.scala.fmt.output: No such file or directory

I have added some debugging code to rules_scala on branch:

https://github.com/gergelyfabian/rules_scala/tree/bazel-7.0-scalafmt-bug

I think that rules_scala is setting up DefaultInfo properly for this target.
Quoting from the rules_scala discussion bazelbuild/rules_scala#1525 (comment)

---- Quote -----

Having https://github.com/bazelbuild/rules_scala/blob/master/scala/private/phases/api.bzl#L91 (that sets up the final rule output):

I have added a debug line just before that:

print("DefaultInfo before the end: %s" % acculmulated_external_providers["DefaultInfo"].default_runfiles.files)

This prints for me:

DEBUG: /home/user/.cache/bazel/_bazel_user/64527517dacf7170f7d914889f83481c/external/io_bazel_rules_scala/scala/private/phases/api.bzl:93:10: DefaultInfo before the end: depset([<generated file example-maven/example-maven.jar>, <generated file external/maven/com/twitter/algebird-core_2.13/0.13.7/processed_algebird-core_2.13-0.13.7.jar>, <generated file external/maven/com/googlecode/javaewah/JavaEWAH/1.1.7/processed_JavaEWAH-1.1.7.jar>, <generated file external/maven/org/scala-lang/modules/scala-collection-compat_2.13/2.1.6/processed_scala-collection-compat_2.13-2.1.6.jar>, <generated file external/maven/org/scala-lang/scala-library/2.13.12/processed_scala-library-2.13.12.jar>, <generated file external/maven/org/scala-lang/scala-reflect/2.13.12/processed_scala-reflect-2.13.12.jar>, <generated file external/maven/org/typelevel/algebra_2.13/2.0.0/processed_algebra_2.13-2.0.0.jar>, <generated file external/maven/org/typelevel/cats-kernel_2.13/2.0.0/processed_cats-kernel_2.13-2.0.0.jar>, <generated file example-maven/format/example-maven/manifest.txt>, <generated file example-maven/example-maven/src/main/scala/mypackage/Maven.scala.fmt.output>, <source file example-maven/src/main/scala/mypackage/Maven.scala>], order = "postorder")

So, this includes the files that I think should be there, specifically: Maven.scala.fmt.output

----- End of Quote -----

If the DefaultInfo is set up properly, then the file should be accessible I guess.

This is reproducible both with Bazel 6.4.0 and 7.0.0rc2, when the --remote_download_toplevel flag is turned on (but with 7.0.0rc2 BwtB is enabled by default).

Which category does this issue belong to?

Rules API

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

git clone https://github.com/gergelyfabian/bazel-scala-example/
cd bazel-scala-example
git checkout bazel-7.0.0rc2
bazel clean
bazel run --remote_download_toplevel //example-maven:example-maven.format-test

Which operating system are you running Bazel on?

Ubuntu 22.04

What is the output of bazel info release?

release 7.0.0rc2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

Ran Bazelisk with bisect and found commit: 9c96529, where BwtB was enabled by default.

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

Related rules_scala issue: bazelbuild/rules_scala#1525

@tjgq
Copy link
Contributor

tjgq commented Nov 8, 2023

There are a couple of odd things going on here, and I'm not sure that any of them are Bazel's fault.

It appears that you're invoking bazel run on a generated file, not an executable rule:

$ bazel query --output=label_kind //example-maven:example-maven.format-test
generated file //example-maven:example-maven.format-test

I don't know why bazel run allows a plain file as an argument, but it seems reasonable to me that running a file won't give access to the runfiles; files have no associated runfiles, rules do.

That brings us to another problem, which is that scala_library isn't an executable rule, so it's not possible to bazel run it either:

$ bazel query --output=label_kind //example-maven:example-maven
scala_library rule //example-maven:example-maven
$ bazel run //example-maven:example-maven
ERROR: Cannot run target //example-maven:example-maven: Not executable

So my suggestion would be to (1) mark scala_library as an executable rule, (2) return the formatter in the DefaultInfo.executable field alongside the runfiles, (3) make sure the formatter looks for the runfiles in the right location (perhaps by using a runfiles library for your implementation language), and finally (4) bazel run the scala_library directly.

As to why you're only running into this now: as it currently stands, your bazel run command is effectively non-hermetic, but bazel run(unlike build actions) doesn't provide a safeguard against non-hermeticity; if Bazel downloads all build outputs, your program will find them anyway, but Bazel has no idea that the dependency is there, and won't realize that they must be downloaded when building without the bytes.

@gergelyfabian
Copy link
Author

Thanks @tjgq for your comment, that is very useful. Will forward this to the rules_scala issue.

@gergelyfabian
Copy link
Author

Closing this issue, as it seems to be a non-hermetic issue in rules_scala itself. Thanks once more!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-Remote-Exec Issues and PRs for the Execution (Remote) team type: bug untriaged
Projects
None yet
Development

No branches or pull requests

5 participants