Open bcmills opened 2 years ago
In this particular case I think GitHub was down...
Change https://go.dev/cl/424594 mentions this issue: cmd/go: disable test cases that depend on gopkg.in
I've been having trouble with -longtest
TryBots all day, and it's only the gopkg.in
tests that are flaking.
(It may be that the underlying problem is on GitHub's side, but it doesn't seem to affect the GitHub-only tests. And long-term we may want to reduce our dependence on those too.)
greplogs -l -e 'FAIL: TestScript.*(?:\n\s+.*)*reading https://gopkg\.in' --since=2022-08-17
2022-09-09T01:04:57-76c94eb/linux-386-longtest
2022-09-09T01:04:57-76c94eb/linux-amd64-longtest
2022-09-09T00:28:56-3c33c3b/linux-386-longtest
2022-08-17T20:02:12-c7f870e/linux-386-longtest
2022-08-17T20:02:12-c7f870e/linux-amd64-longtest
2022-08-17T18:46:05-90466e1/linux-386-longtest
2022-08-17T18:34:10-ebda5a7/linux-amd64-longtest
2022-08-17T18:01:43-e1fd51e/linux-amd64-longtest
2022-08-17T17:47:37-bc80579/linux-amd64-longtest
2022-08-17T17:39:58-04d8c23/linux-amd64-longtest
2022-08-17T17:39:50-9b988c9/linux-386-longtest
2022-08-17T17:39:50-9b988c9/linux-amd64-longtest
2022-08-17T17:39:31-ce7aae5/linux-386-longtest
2022-08-17T17:39:31-ce7aae5/linux-amd64-longtest
2022-08-17T17:39:16-901b923/linux-386-longtest
2022-08-17T17:17:46-2a0327b/linux-386-longtest
2022-08-17T16:11:11-ea6cb02/linux-386-longtest
2022-08-17T16:08:04-bd1bff4/linux-amd64-longtest
Found new dashboard test flakes for:
#!watchflakes
post <- pkg == "cmd/go" && test == "TestScript" && `reading https://gopkg\.in`
Found new dashboard test flakes for:
#!watchflakes
post <- pkg == "cmd/go" && test == "TestScript" && `reading https://gopkg\.in`
Found new dashboard test flakes for:
#!watchflakes
post <- pkg == "cmd/go" && test == "TestScript" && `reading https://gopkg\.in`
Found new dashboard test flakes for:
#!watchflakes
post <- pkg == "cmd/go" && test == "TestScript" && `reading https://gopkg\.in`
Change https://go.dev/cl/454503 mentions this issue: cmd/go: skip TestScript/mod_replace_gopkgin
@gopherbot, please backport to Go 1.18 and 1.19. This test is very flaky lately, so we should at least backport a skip for it.
Backport issue(s) opened: #57057 (for 1.18), #57058 (for 1.19).
Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.
Change https://go.dev/cl/454839 mentions this issue: [release-branch.go1.19] cmd/go: skip TestScript/mod_replace_gopkgin
Change https://go.dev/cl/454840 mentions this issue: [release-branch.go1.18] cmd/go: skip TestScript/mod_replace_gopkgin
Found new dashboard test flakes for:
#!watchflakes
post <- pkg == "cmd/go" && test == "TestScript" && `reading https://gopkg\.in`
Change https://go.dev/cl/466857 mentions this issue: [release-branch.go1.19] cmd/go: skip test cases that depend on gopkg.in
Change https://go.dev/cl/466860 mentions this issue: cmd/go: remove tests that assume lack of new versions of external modules
Change https://go.dev/cl/466861 mentions this issue: [release-branch.go1.20] cmd/go: remove tests that assume lack of new versions of external modules
Change https://go.dev/cl/466862 mentions this issue: [release-branch.go1.19] cmd/go: remove tests that assume lack of new versions of external modules
Change https://go.dev/cl/473276 mentions this issue: cmd/go: declare net hosts in script tests
The
gopkg.in
service has occasional downtime (most recently https://github.com/niemeyer/gopkg/issues/78). Some of thecmd/go
tests ofgopkg.in
modules are isolated from outages by the Go module proxy, but unfortunately others fail when the service is down.As far as I can tell, the
go-import
metadata served bygopkg.in
is mostly static. (It may add some value in serving up-to-datego-source
metadata, butcmd/go
does not depend on that metadata.) Since we're going to have a test-local HTTPS server anyway for #27494, perhaps we can migrate thegopkg.in
tests to use that server with staticgo-import
metadata instead.