experimental_remote_downloader should be ignored for file:// urls #26810
Description
Description of the bug:
If you're using --experimental_remote_downloader to point to your remote cache, and you have a http_whatever that uses a file:// url (likely for local testing), that will fail to "download" with something like:
Error in download: java.io.IOException: io.grpc.StatusRuntimeException: NOT_FOUND: file:/tmp/foo.txt: rpc error: code = Unavailable desc = failed to fetch "file:/tmp/foo.txt": HTTP GET failed: Get "file:/tmp/foo.txt": unsupported protocol scheme "file"
ERROR: no such package '@@+http_file+something//file': java.io.IOException: io.grpc.StatusRuntimeException: NOT_FOUND: file:/tmp/foo.txt: rpc error: code = Unavailable desc = failed to fetch "file:/tmp/foo.txt": HTTP GET failed: Get "file:/tmp/foo.txt": unsupported protocol scheme "file"
ERROR: /tmp/foo/BUILD.bazel:1:8: //:foo depends on @@+http_file+something//file:file in repository @@+http_file+something which failed to fetch. no such package '@@+http_file+something//file': java.io.IOException: io.grpc.StatusRuntimeException: NOT_FOUND: file:/tmp/foo.txt: rpc error: code = Unavailable desc = failed to fetch
"file:/tmp/foo.txt": HTTP GET failed: Get "file:/tmp/foo.txt": unsupported protocol scheme "file"
In this case I think the remote downloader should probably just be ignored?
--experimental_remote_downloader_local_fallback fixes this but im not sure that's ideal to set if you don't otherwise want things to fallback? (I'm not sure what cases that would be)
It also still warns in that case which might be noisy if you were using file urls for more than just testing
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
No response
Which operating system are you running Bazel on?
No response
What is the output of bazel info release?
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 HEAD ?
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response