Bazel: http_archive doesn't work well for Windows

[iirina]

The following scenario is not well supported on Windows:

• declare an http_archive which contains top-level files
• one of the top-level files in the http_archvie is invoked by a bazel command

The bazel command only succeeds if it's a clean build, otherwise fails with an error similar to:

ERROR: Source forest creation failed: D:/b/sdlshnzi/execroot/io_bazel/_tmp/2713b7a92d8298dcf32c3b44de75c8b1/root/sb26b24g/execroot/main/external/remote_java_tools/JavaBuilder_deploy.jar (Permission denied)

IIUC this is because Bazel tries to remove all non-symlink directories/files from the execroot tree. On Windows there are no symlinks for regular files and bazel uses copies of the original files, so bazel tries to remove all the files downloaded from http_archive. If they are already in use by some process (this happens if they were already invoked/used by previous bazel runs) bazel fails to delete them.

This issue is a generalization of #7440, which was fixed by placing all top-level files under a directory in the http_archive.

[iirina]

cc @laszlocsomor @lberki

[meteorcloudy]

@laszlocsomor Since you are working on new_local_repository already, can you also look into this?

[meteorcloudy]

Is there an easy way to put JavaBuilder_deploy.jar under a sub-directory?
This issue is also causing Bazelisk + Incompatible flags to fail on Windows
https://buildkite.com/bazel/bazelisk-plus-incompatible-flags/builds/45#4b55ba23-99ba-49c0-9cd6-9dee480c51ad

[laszlocsomor]

@meteorcloudy : I'm confused -- that build is green.

[meteorcloudy]

@laszlocsomor When running with Bazelisk, the job will continue and be green (because we expect some failures when using incompatible flags). But if check the Running Bazel with no incompatible flags section at the end of the log, you'll see the build failed with this error. And because of this, the pipeline listed Bazel on Windows as an already failing job.

[laszlocsomor]

@iirina : How is the //external:remote_java_tools repository created? With 0.23.2, I get:

C:\src\bazel>bazel query //external:remote_java_tools --output=build
# /DEFAULT.WORKSPACE.SUFFIX:208:1
http_archive(
  name = "remote_java_tools",
  urls = ["https://mirror.bazel.build/bazel_java_tools/java_tools_pkg-0.1.tar.gz"],
  sha256 = "df33ddb3054f0ee70389368bd1dc2efe72eeb1f489dbcdf948f3f3b3058646b7",
  build_file = "@bazel_tools//tools/jdk:BUILD.pkg",
)

Contents of java_tools_pkg-0.1.tar.gz:

  $ tar tf java_tools_pkg-0.1.tar.gz | grep JavaBuilder_deploy.jar
./JavaBuilder_deploy.jar
./VanillaJavaBuilder_deploy.jar

We need to repackage this tar and move the .jar files to subdirectories, then update jdk.WORKSPACE, then release Bazel. Is that correct?

[iirina]

remote_java_tools comes from the http_archive you mentioned. If you want to update the java tools version then yes the archive has to be repackaged, uploaded to GCS and jdk.WORKSPACE needs to be updated before a Bazel release.

We released the java tools several times after 0.1 (I'm surprised that bazel 0.23 was released with the first version). The java tools versions >= 0.4 have all their content under a java_tools top level directory and this issue is not present anymore. If we want to do a patch release we can just update jdk.WORKSPACE to point to the latest java tools version (I can help with that).

[meteorcloudy]

I don't think this is a regression, so maybe a patch release is not necessary?
But we do want to fix this before flipping --incompatible_use_toolchain_providers_in_java_common

[iirina]

@meteorcloudy Great, then it is already fixed. :)

[iirina]

@meteorcloudy @laszlocsomor any news on this issue? I'm thinking of adding a top-level WORKSPACE file to my http_archive, which will make it fail on Windows.

[laszlocsomor]

No updates.
But I don't think a WORKSPACE file is problematic: no process will hold it open.
The problem is with files that we run as subprocesses or otherwise hold open handles to.

[iirina]

Oh, that's great! This applies to BUILD files as well, IIUC?

[laszlocsomor]

Yes it does. If no subprocess holds this file open, you're fine. (Jar files and data files of persistent workers are risky.)

[iirina]

Thanks!

[laszlocsomor]

@iirina : does this bug still matter? It's worth documenting that no file from the root of an archive should be used in a worker, but is there anything beyond that?

[iirina]

I'll leave it up to the Windows team to decide on the priority/fix. The java rules are not affected by this issue anymore, so from this point of view it doesn't matter. Documenting this behavior is definitely helpful. Depending on what type of archives the Bazel users have this may or may not be an issue in the future.