-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
all: audit which generate directives depend on version of vendored packages #43440
Comments
dmitshur
added
the
NeedsFix
The path to resolution is known, but the work has not been done.
label
Dec 31, 2020
Change https://golang.org/cl/283643 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jan 20, 2021
Expand the scope of the TestAllDependenciesVendored test to check that all modules in GOROOT are tidy, that packages are vendored, the vendor content matches the upstream copy exactly, and that bundled packages are re-generated (using x/tools/cmd/bundle at the version selected in cmd module; this is deterministic and guaranteed to be updated over time). This is done in a conceptually simple way: 1. Make a temporary copy of the entire GOROOT tree (except .git), one that is safe to modify. 2. Run a list of high-level commands, the same commands we expect Go developers should be able to run in a normal complete GOROOT tree to make it clean and tidy. 3. Diff the end result with the original GOROOT tree being tested to catch any unexpected differences. The current set of commands that are run require the cmd/go command, and a functional compiler itself (because re-generating the syscall package involves a directive like //go:generate go run [...]). As a result, copying a large majority of the GOROOT tree is a requirement. Instead of looking for the few files or directories that can we can get away not copying (e.g., the testdata directories aren't strictly needed at this time), we opt not to optimize and just do the simple copy. This is motivated by these reasons: • We end up having a complete, normal GOROOT tree, one that happens to be located at another path. There's a very high likelihood that module management/code generation commands, both the ones we run today and any additional ones that we might want to add in the future, will result in correct results even as the Go project evolves over time. • Having a completely stand-alone copy of the GOROOT tree without symlinks minimizes the risk of some of the module management/code generation commands, either now or in the future, from modifying the user's original GOROOT tree, something that should not happen during test execution. Overlays achieved with symlinks work well when we can guarantee only new files are added, but that isn't the case here. • Copying the entire GOROOT (without .git), takes around 5 seconds on a fairly modern computer with an SSD. The most we can save is a couple of seconds. (We make some minor exceptions: the GOROOT/.git directory isn't copied, and GOROOT/{bin,pkg} are deemed safe to share and thus symlink instead of copying. If these optimizations cease to be viable to make, we'll need to remove them.) Since this functionality is fairly expensive to execute and requires network access, it runs only when the test is executed without -short flag. The previous behavior of the TestAllDependenciesVendored test is kept in -short test mode. all.bash runs package tests with -short flag, so its behavior is unchanged. The expectation is that the new test will run on some of the longtest builders to catch problems. Users can invoke the test manually 'go test cmd/internal/moddeps' (and it's run as part of 'go test cmd', again, only when -short flag isn't provided). On a 2017 MacBook Pro, a successful long test takes under 15 seconds, which should be within scope of all long tests that are selected by 'go test std cmd'. We may further adjust when and where the test runs by default based on our experience. Fixes #36852. Fixes #41409. Fixes #43687. Updates #43440. Change-Id: I9eb85205fec7ec62e3f867831a0a82e3c767f618 Reviewed-on: https://go-review.googlesource.com/c/go/+/283643 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Trust: Dmitri Shuralyov <dmitshur@golang.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Go standard library uses vendored copies of some external packages. These packages are updated as needed to fix bugs or bring in new features, and in bulk as part of release cycle maintenance (issue #36905).
There are some generate directives that depend on data in vendored packages, and so they need to be re-run whenever vendored versions change.
We are currently aware of:
So at the very least:
go generate -run=bundle net/http
needs to be re-run whenever golang.org/x/net version changesgo generate syscall internal/syscall/...
whenever golang.org/x/sys version changesThis is the tracking issue to audit the rest and find out if there any more. We can incorporate findings here into tests that are being added for #36852 and #41409. Thanks to @bcmills for raising this question in CL 275446 (comment).
As of commit 20d0991, there are a total of 60 generate directives in GOROOT/src, not counting testdata and vendored packages:
CC @golang/release.
The text was updated successfully, but these errors were encountered: