'file:' scheme URLs are sent through --experimental_remote_downloader #17771
Labels
P3
We're not considering working on this, but happy to review a PR. (No assignee)
stale
Issues or PRs that are stale (no activity for 30 days)
team-Remote-Exec
Issues and PRs for the Execution (Remote) team
type: bug
Description of the bug:
I'm using Aspect's rules_js, and they've made recent changes where they're using
repository_ctx.download()
to handle local files using thefile:
scheme. (According to the comment, they've added this to handle binary files.)However, even though it's a local
file:
-scheme URL, this ends up going through the--experimental_remote_downloader
Their snippet of code:
Normally this works as expected, but when used in conjunction with
--experimental_remote_downloader
, the localfile:
scheme requests are going to our remote downloader service which sits on a remote machine (and therefore, of course, wouldn't have access to the host machine's local files).I created an issue on their repo here: aspect-build/rules_js#916, but seems like this may be a Bazel bug.
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Create a repository rule that tries to "download" a
file:
scheme URL, while having--experimental_remote_downloader
in use. Bazel will delegate to the remote downloader to attempt to "download" the local file.It seems that
file:
scheme URLs should not go to the remote downloader, and should instead always be handled by the local downloader.Which operating system are you running Bazel on?
MacOS Monterrey
What is the output of
bazel info release
?release 6.0.0
If
bazel info release
returnsdevelopment 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
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
Even with
--experimental_remote_downloader_local_fallback
(which somewhat works around the problem), we're still slowing down builds by making requests for all of these local files and we get warnings with long stack traces for each local file that is passed to the remote downloader. Example:If it's not possible to change the behavior of
file:
scheme URLs going to the remote downloader at this point though, perhaps there needs to be another flag added, something like--experimental_remote_downloader_file_scheme_local
(or something of the sort - naming is hard :))The text was updated successfully, but these errors were encountered: