Description
This report is part of a series, filled at the request of @mdempsky, focused at making Go modules integrator-friendly.
Please do not close or mark it as duplicate before making sure you’ve read and understood the general context. A lot of work went into identifying problems points precisely.
Needed feature
Go needs an official go mod build
command that builds all the binaries provided by a particular Go module.
Constrains
-
the input should be:
- a
module path
, or - a
module path
+module version
, or - the
filesystem path
of a specificmod
module descriptor- either the
go.mod
file at the root of an unpacked module tree, or - a
mod
file inside a goproxy hierarchy
- either the
- a
-
all the usual
go build
flags should apply -
the
destination
should be any binary directory path the user specifies -
for compatibility with existing tooling, a separate optional
prefix
flag should allow pre-pending a path to the destination:- ie pretend working on
destination
, actually work onfilepath.Join(prefix, destination)
- that is typically used to prepare deployment to
canonical_path
, using a/prefix/canonical_path
staging directory
- ie pretend working on
-
to allow integration with CI/CD software, the command should optionally output a list of the files it created, in machine-readable format, to a user-specified result file
- the result file path is not affected by
destination
- the result file lists paths without
prefix
, since the command is pretending to write directly intodestination
- this is similar to the behaviour of
go mod pack
(cmd/go: [modules + integration] go mod pack, pack sources as module files #31302) and should use the same conventions
- the result file path is not affected by
-
the command should allow selecting (or not) the following binary sets:
- target binaries (binaries the module was created for, intended for general use)
- unit test helpers (ancillary binaries, created for the needs of unit tests, that only require the compiler)
- integration test helpers (ancillary binaries, created for the needs of integration tests, that require more things than just the compiler to run see also cmd/go: [modules + integration] go mod buildrequires, list the build requirements of a set of unpacked modules #31300)
- example binaries, that have no use in production or tests
- though most of them won’t build as is, and projects should be incentivised to split them in separate example modules
-
the command should work in secure no-internet-download mode. In that mode it should fail if one of the modules it needs for building is not available in the cache or configured goproxy (cmd/go: [modules + integration] use several goproxy sources simultaneously #31304) sources
- it should not get stuck forever waiting on the CI/CD firewall to let
go get
download from the internet
- it should not get stuck forever waiting on the CI/CD firewall to let
Motivation
Go modules are wonderful and exciting, until you realise they only deal with the code download part. One stills need to dissect individual Go packages in the next stages of a CI/CD Go-related job.
The Go module concept should be extended to the rest of Go code processing phases.