-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/build/cmd/golangbuild: run subrepo tests from outside their repositories #34352
Comments
Change https://golang.org/cl/196258 mentions this issue: |
Files named go.mod define a module boundary and punch a hole in the repository when the module is fetched with go get. We had a couple in testdata. Get rid of them. In one case the changes I made to produce a module cache in packagestest were enough. In the other, the test needs multiple minor/patch versions of the same module, which we have no provision for. Rename them to "definitelynot_go.mod" in the repo and fix it up in the test. Updates golang/go#34352 Change-Id: I284578b3aebb0f1fec3ddb4bef0df24f050d0636 Reviewed-on: https://go-review.googlesource.com/c/tools/+/196258 Run-TryBot: Heschi Kreinick <[email protected]> Reviewed-by: Ian Cottrell <[email protected]>
Files named go.mod define a module boundary and punch a hole in the repository when the module is fetched with go get. We had a couple in testdata. Get rid of them. In one case the changes I made to produce a module cache in packagestest were enough. In the other, the test needs multiple minor/patch versions of the same module, which we have no provision for. Rename them to "definitelynot_go.mod" in the repo and fix it up in the test. Updates golang/go#34352 Change-Id: I284578b3aebb0f1fec3ddb4bef0df24f050d0636 Reviewed-on: https://go-review.googlesource.com/c/tools/+/196258 Run-TryBot: Heschi Kreinick <[email protected]> Reviewed-by: Ian Cottrell <[email protected]>
/cc @ianthehat FYI. This is the issue I mentioned to you in person just now. |
This is implemented in the new build system (LUCI); see #60666 (comment). At this point I'm confident we won't go back and implement this in x/build/cmd/coordinator, so closing as wontfix. |
The current implementation in LUCI does not appear to have high enough fidelity to catch the sort of problems that motivated this issue. For example, #65258 is not currently caught by the LUCI builders for the Perhaps the tests are currently run from outside their module, but without cutting off the module contents at module boundaries? At any rate: reopening as “not actually fixed on LUCI”. |
The reason #65258 is not currently caught by the LUCI builders is because the current implementation requires there not to be local replace directives, and x/telemetry is one of the 3 repos that does, and their owners have decided to opt out of this behavior. See here. If the local replace directive is removed and x/telemetry owners would like this check to apply, it's a matter of removing "telemetry" from |
This feature was implemented in LUCI and is working for the repos that haven't opted out. Retitling for LUCI, and closing as fixed via crrev.com/c/4598622 (and crrev.com/c/4651891). |
(This is essentially the
golang.org/x/[…]
version of #30316.)go.mod
files intestdata
directories cut off the directory from the rest of the module (see #27852). As a result, the corresponding tests are likely to fail.Unfortunately, at least one of the
golang.org/x
repos already includes such files: I am aware of some ingolang.org/x/tools/go/packages/testdata
(CC @heschik, @matloob), and there may be others as well.Rather than expecting all Go developers to remember to avoid adding extraneous
go.mod
files, we should configure builders and TryBots to run the tests forgolang.org/x
modules outside the module, either in addition to or instead of running them from within a cloned repository.(The simplest alternative I am aware of is to construct a symlink overlay within a temporary directory, as is done in various
misc/cgo
tests.)CC @dmitshur @toothrot @bradfitz
The text was updated successfully, but these errors were encountered: