cmd/go, cmd/go/internal/modfetch: update tests not to rely on external domains that only an individual maintainer has access to #40519
Labels
GoCommand
cmd/go
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Testing
An issue that has been verified to require only test changes, not just a test failure.
Milestone
(Factoring out comment #28856 (comment) into a separate issue, since it's slightly different than #28856 and out of scope for that issue.)
Some of
cmd/go
andcmd/go/internal/modfetch
tests currently rely on content hosted onrsc.io
,swtch.com
, andinsecure.go-get-issue-15410.appspot.com
domains, and historically a single individual had access to those projects. They have been very reliable for many years, and since they're explicitly created as test modules forcmd/go
tests, and we don't expect the content to change for due to active project development, as in issue #28856.However, we still want these tests not to have a single point of failure, since an individual person may be unavailable (e.g., due to being on a vacation), and it is important that we're able to fix any issues if they come up in the future, or if the test data needs to be updated for some reason.
Perhaps this can be resolved by granting access to those hosts to the cmd/go team (as suggested by @rsc and @andybons), or by moving them to an existing host that the cmd/go team has access to (such as vcs-test.golang.org), or by starting up a test-local server (as suggested by @bcmills in #28856 (comment)).
Details of tests that were affected recently (from https://storage.googleapis.com/go-build-log/3c347861/linux-amd64-longtest_bb29e807.log, https://storage.googleapis.com/go-build-log/2229151e/linux-386-longtest_dca9ed82.log, and https://storage.googleapis.com/go-build-log/0fcc0a58/linux-amd64-longtest_642c58db.log):
/cc @bcmills @jayconrod @matloob @rsc @andybons
The text was updated successfully, but these errors were encountered: