Usage go_repository results in surprising behavior due to go mod download usage

[mauriciogg]

What version of gazelle are you using?

v0.29.0

What version of rules_go are you using?

N/A

What version of Bazel are you using?

6.5

Does this issue reproduce with the latest releases of all the above?

Yes

What operating system and processor architecture are you using?

Linux / arm64 and x86_64

What did you do?

I'm trying to build a bazel target that depends on the bazel-gazelle repo using the --experimental_downloader_config bazel flag

What did you expect to see?

the build to succeed

What did you see instead?

the build fails due to a timeout when fetching a go_repository dependency because go mod download is trying to talk to proxy.golang.org. with the following error

Error in fail: failed to fetch com_github_bazelbuild_buildtools: fetch_repo: github.com/bazelbuild/[email protected]: Get "https://proxy.golang.org/github.com/bazelbuild/buildtools/@v/v0.0.0-20230111132423-06e8e2436a75.info": dial tcp 142.251.215.241:443: i/o timeout
2024-08-26 16:12:20,388     ERROR: /mnt/jenkins/home/jenkins/workspace/SUT-Base-Snowflake/GlobalServices/BUILD.bazel:159:19: //GlobalServices:update_build_files depends on @com_github_bazelbuild_buildtools//buildozer:buildozer in repository @com_github_bazelbuild_buildtools which failed to fetch. no such package '@com_github_bazelbuild_buildtools//buildozer': failed to fetch com_github_bazelbuild_buildtools: fetch_repo: github.com/bazelbuild/[email protected]: Get "https://proxy.golang.org/github.com/bazelbuild/buildtools/@v/v0.0.0-20230111132423-06e8e2436a75.info": dial tcp 142.251.215.241:443: i/o timeout
2024-08-26 16:12:20,399     ERROR: Analysis of target '//GlobalServices:update_build_files' failed; build aborted: Analysis failed

This is technically not a bug in bazel-gazelle but it results in a surprising behavior when a downloader config is used for the build, since there is an expectation that all public urls will be rewritten to internal only hosts, but because go_repository in this instance does not use the bazel mechanisms to download artifacts, the download configuration is completely ignored here. I'm not sure what the resolution is here, but at least it should be documented

see golang/go#63562

[annapst]

I'm observing the same issue, is there an alternative way to overwrite https://proxy.golang.org with an internal url, since downloader config doesn't help?

[fmeum]

You can set GOPROXY to your internal URL via --repo_env.

The proper fix is to resolve #1936 and have fetching use the Bazel downloader. Happy to review PRs that do this, it doesn't looks hard.