tree ea15f8830d2b862e9d56acd850d34eff714842dd
parent 65ec7a26da224b4f5948de795d09b61a58fb4470
author Dmitri Shuralyov <dmitshur@golang.org> 1565464578 -0400
committer Dmitri Shuralyov <dmitshur@golang.org> 1565632533 +0000

cmd/release: embed releaselet.go source code statically

Previously, the release binary dynamically looked for the releaselet.go
source code. It first checked in the current working directory, and
then used the go/build package to find the location of source code of
golang.org/x/build/cmd/release package on disk.

The release binary is not generally executed by hand, rather it is used
internally by releasebot command. That makes it hard to know in advance
where the current working directory for release will be (that directory
is $HOME/go-releasebot-work/<release> that releasebot creates itself).

Further, with the proliferation of module mode, it's no longer viable
to be able to find the location of a package by its import path via
go/build.Import. As a result, there's now a higher risk of cmd/release
not finding, or finding a wrong version of releaselet.go.

Change the release binary to instead statically embed the releaselet.go
source code as a constant string, in a static.go file that is generated
via a go:generate directive.

Add a test to ensure the embedded copy of releaselet.go doesn't get out
of sync.

The embedding approach was loosely based on approach taken in package
golang.org/x/tools/godoc/static, but it was simplified for the smaller
needs of cmd/release (i.e., embedding a single text file). We rely on
fmt's %q verb to do the escaping, which has the risk of changing between
Go versions, but it's unlikely to happen often to warrant worrying yet.

Fixes golang/go#33443

Change-Id: Ie7a9481c33a7d9668d696d3827e5681b07b37094
Reviewed-on: https://go-review.googlesource.com/c/build/+/189817
Reviewed-by: Filippo Valsorda <filippo@golang.org>