Calls to https://go.dev/dl/?mode=json are breaking airgapped builds - provide way to avoid these about rules_go HOT 6 OPEN

This is where the request is made:

from rules_go.

This is an interesting problem that I think can be solved by introducing an intermediate extension that records the extracted information in the MODULE.bazel.lock file. I'll give this some more thought and try to implement it.

from rules_go.

@fmeum thank you for looking at this! For us, we cannot source manage MODULE.bazel.lock because we don't use git and the unsupported merge of this huge file (it is 2MB for us) will be incorrect more often than not. So a solution involving direct specification of the inputs in MODULE.bazel or in a separate file would be much better

from rules_go.

@peakschris When you say "don't use Git", what are you using instead and why does that prevent you from checking in MODULE.bazel.lock? Bazel 7.2.0rc1 comes with a revised lockfile format that is much more VCS friendly and less verbose.

Generally speaking, I would like to first find a general solution that works out of the box, but I'm sure we'll find a way to support your use case.

from rules_go.

@fmeum we use a custom VCS layer, with perforce as the backend. The VCS layer was written years ago and is in maintenance mode now, so it's practically impossible to get significant changes made. It does not support custom merge drivers.

We also have a significant problem with contentious files that cause 'MR's to back up in our test pipeline. MODULE.bazel.lock would be a massively contentious file.

So there are two issues:

1. MODULE.bazel.lock can't be auto-merged in our system and will be broken often. I can't give a tool to developers to use manually as some merge steps happen in CI via a web UI.
2. MODULE.bazel.lock would cause MRs to queue up and retest. We don't have a good merge train like github.

I'm sure this will be an issue for others too, who have similar constraints. I don't have these issues with rules_js, etc, and I like their approach of providing the inputs to the toolchain in the MODULE.bazel file.

We can split up MODULE.bazel via include statements that allow different elements of the build to be specified in smaller files that are not contentious and are obvious to merge graphically.

Thanks again for thinking about this

from rules_go.

I've actually stumbled on a way to avoid these queries:

bazel_dep(name = "rules_go", version = "0.47.1")
go_sdk = use_extension("@rules_go//go:extensions.bzl", "go_sdk")
go_sdk.download(
    version = "1.22.3",
    # explicitly specify SDK names/checksums to avoid a query which fails in airgapped builds
    # get checksums from https://go.dev/dl/?mode=json&include=all
    sdks = {
        "linux_amd64": ("go1.22.3.linux-amd64.tar.gz", "8920ea521bad8f6b7bc377b4824982e011c19af27df88a815e3586ea895f1b36"),
        "windows_arm64": ("go.1.22.3.windows-arm64.tar.gz", "59b76ee22b9b1c3afbf7f50e3cb4edb954d6c0d25e5e029ab5483a6804d61e71"),
    },
)

Would it be possible to update documentation (https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst#go_download_sdk) to include examples of use with Modules? This is what I was missing.

from rules_go.