--distdir is not working in combination with --experimental_downloader_config

[pilkjaer]

Description of the problem / feature request:

Related to 9d29464.
When using combination of --distdir and --experimental_downloader_config it seems to be a problem with resolving paths.
I have a self-contained Bazel installation in a folder that I specify using --distdir. Folder contains all downloaded files that Bazel need (I use bazel sync for that) so no downloads from Internet are necessary. When applying --experimental_downloader_config flag with "block *" value all paths are being replaced including Bazel internal ones. So files needed by Bazel and present in distdir can no longer be used which results in build error.

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

Build with --experimental_downloader_config having "block *" as well as --distdir pointing to the location of a complete Bazel installation.

What operating system are you running Bazel on?

Red Hat Enterprise Linux Server release 7.8 (Maipo)

What's the output of bazel info release?

release 3.7.0

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

I run 8cffdf1 commit which is 3.7.0 release commit.

Have you found anything relevant by searching the web?

No

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

$ bazel build --experimental_remote_downloader_config=.bazel_download_config ...
....
INFO: Rewritten [https://mirror.bazel.build/github.com/bazelbuild/rules_cc/archive/8bd6cd75d03c01bb82561a96d9c1f9f7157b13d0.zip, https://github.com/bazelbuild/rules_cc/archive/8bd6cd75d03c01bb82561a96d9c1f9f7157b13d0.zip] as []
....
ERROR: no such package '@rules_cc//cc': java.io.IOException: Cache miss and no url specified

File 8bd6cd75d03c01bb82561a96d9c1f9f7157b13d0.zip is present in the folder that I provide via --distdir.

[sluongng]

bazel/src/main/java/com/google/devtools/build/lib/bazel/repository/downloader/DownloadManager.java

Line 170 in 9d29464

mainUrl.toString(), "Checking " + cacheKeyType + " of " + candidate));

there is probably something here that we can patch out to use the pre-rewritten url instead.

[sluongng]

I hacked around this a bit yesterday but couldnt find any tests for distdir in the context of DownloadManager

That would left me with only a few options:

1. Write some tests for current distdir interaction with DownloadManager before attempting to fix this issue
2. Try to get the Java debugger working in IntelliJ and manually test the fix with debugger in Bazel code base
3. Just compile bazel with some Event.warn() printed out and test it manually.

I'm trying to explore possibility of doing (1), but if it takes me too much time then I will try (2) or (3) after.

[nickbreen]

I've worked-around this by:

1. rewriting the URL(s) for any item in a distdir to a URL with a "bogus" FQDN
2. adding an allow for the "bogus" FQDN

e.g.

rewrite (mirror.bazel.build/.*) http://bogus.localhost/$1
allow bogus.localhost
block *

It kind of still works for us: if the distdir does not contain the expected file then it'll try and download and fail anyway.