Skip to content
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: user-facing golang.org/x repos need to stay green #11811

Open
rsc opened this issue Jul 21, 2015 · 89 comments
Open

all: user-facing golang.org/x repos need to stay green #11811

rsc opened this issue Jul 21, 2015 · 89 comments
Labels
NeedsFix The path to resolution is known, but the work has not been done. recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. release-blocker
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Jul 21, 2015

We need to get the subrepos green consistently for 1.5 and moving forward.

edit 2023-06-23 by @heschi:
Modules that are vendored into the main release, such as net and sys, as well as user-facing libraries like tools and text, must be healthy before a release can be issued. Other modules are out of scope.

@rsc rsc added this to the Go1.5 milestone Jul 21, 2015
gopherbot pushed a commit to golang/tools that referenced this issue Jul 29, 2015
Update golang/go#11811

Change-Id: I3d875acf58a015fa4cae16473a118ac8196b9b44
Reviewed-on: https://go-review.googlesource.com/12789
Reviewed-by: Andrew Gerrand <adg@golang.org>
@gopherbot
Copy link

CL https://golang.org/cl/12788 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/12830 mentions this issue.

gopherbot pushed a commit to golang/tools that referenced this issue Jul 29, 2015
Update golang/go#11811

Change-Id: I1f8977cf8eed84936c7c2b568f87abe88f5723f9
Reviewed-on: https://go-review.googlesource.com/12788
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@gopherbot
Copy link

CL https://golang.org/cl/12832 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/12765 mentions this issue.

alandonovan pushed a commit to golang/tools that referenced this issue Jul 29, 2015
Some standard library dependencies have changed (packages and files).
Both ExampleConfig_CreateFromFiles and ExampleConfig_Import Output
needs to be adjusted. Do that.

Update golang/go#11811

Change-Id: I523f2adc1aa46f0932a71ccb23dd7c5a6b07fb27
Reviewed-on: https://go-review.googlesource.com/12832
Reviewed-by: Alan Donovan <adonovan@google.com>
gopherbot pushed a commit to golang/tools that referenced this issue Jul 30, 2015
Update golang/go#11811

Change-Id: Ic5f1ea87c88d563b6e0ef2d44042e28a9ea03a03
Reviewed-on: https://go-review.googlesource.com/12830
Reviewed-by: Robert Griesemer <gri@golang.org>
@gopherbot
Copy link

CL https://golang.org/cl/12838 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/13008 mentions this issue.

griesemer added a commit to golang/tools that referenced this issue Jul 31, 2015
For golang/go#11811.

Change-Id: I130f9608840177cfb7fb9fae30765fcb5aa77411
Reviewed-on: https://go-review.googlesource.com/13008
Reviewed-by: Russ Cox <rsc@golang.org>
@gopherbot
Copy link

CL https://golang.org/cl/13032 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/13009 mentions this issue.

griesemer added a commit to golang/tools that referenced this issue Jul 31, 2015
This should help on slower machines.

For golang/go#11811.

Change-Id: Ibb5d5bf0f6cedcda6437ef0ee3fc1f4ba89dab90
Reviewed-on: https://go-review.googlesource.com/13009
Reviewed-by: Ian Lance Taylor <iant@golang.org>
griesemer added a commit to golang/tools that referenced this issue Jul 31, 2015
The output of ExampleConfig_CreateFromFiles and ExampleConfig_Import
are different for Windows that for other platforms: They contain
internal/syscall/windows packages and unicode/utf16 not present in
the output for other platforms.

For golang/go#11811.

Change-Id: Id391fbeec8123616da86cb68fc3cefcd513b2493
Reviewed-on: https://go-review.googlesource.com/13032
Reviewed-by: Ian Lance Taylor <iant@golang.org>
griesemer added a commit to golang/tools that referenced this issue Jul 31, 2015
Attempt to make build work on Plan 9.

For golang/go#11811.

Change-Id: I37a5eaef441262342994a8f77c86aa5e120deea7
Reviewed-on: https://go-review.googlesource.com/13033
Reviewed-by: Ian Lance Taylor <iant@golang.org>
griesemer added a commit to golang/tools that referenced this issue Jul 31, 2015
See golang/go#11975.
For golang/go#11811.

Change-Id: I56ee20cd798bf963afdf3c81c4745f07850f6dcc
Reviewed-on: https://go-review.googlesource.com/13034
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot
Copy link

CL https://golang.org/cl/12916 mentions this issue.

gopherbot pushed a commit to golang/crypto that referenced this issue Aug 2, 2015
Update golang/go#11811

The increased default concurrency in Go 1.5 showed up a test flake in
the TestHostKeyCert test. Under load, when the client provided incorrect
data, both sides would race to tear down the connection, which would often
lead to the server side, running in its own goroutine to see an unexpected
EOF or connection reset.

Fix this flake (and the incorrect use of t.Fatalf) by passing the error back
to the main goroutine for inspection. This also lets us ignore the expected
error in the unsuccessful path

Change-Id: I5a95c6d240479e9d537f34177e5ca8023b1b08e9
Reviewed-on: https://go-review.googlesource.com/12916
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
bradfitz added a commit to golang/exp that referenced this issue Aug 4, 2015
…empty

The builders don't have X. (notably Darwin)

Perhaps the Linux ones should. Or some should. Please file a separate bug for that.

Somebody else might want to upstream this fix to BurntSushi.

Updates golang/go#11811

Change-Id: I6d270a83fc59a3923723b5bfbd0b92057a484a1c
Reviewed-on: https://go-review.googlesource.com/12765
Reviewed-by: Nigel Tao <nigeltao@golang.org>
@gopherbot
Copy link

CL https://golang.org/cl/13252 mentions this issue.

rsc added a commit to golang/text that referenced this issue Aug 5, 2015
For golang/go#11811.
Fixes golang/go#11927.

Change-Id: Ie60c687ba93aaeb6c164413289f474be63e0224f
Reviewed-on: https://go-review.googlesource.com/13252
Reviewed-by: Robert Griesemer <gri@golang.org>
@gopherbot
Copy link

CL https://golang.org/cl/13268 mentions this issue.

griesemer added a commit to golang/tools that referenced this issue Aug 6, 2015
For golang/go#11811.

Change-Id: Icf16a2d47fcf2fe0d79dd825ccb851a3d63a660f
Reviewed-on: https://go-review.googlesource.com/13268
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
codegod2222 added a commit to codegod2222/oauth_go that referenced this issue Nov 25, 2022
See https://build.golang.org/log/c3e046245c4eafbb7b2571ef9ac144b0d29ba2b5

Updates golang/go#11811

Change-Id: I16d2ac26dcda123e1bd8c456e490f6ca45111d24
Reviewed-on: https://go-review.googlesource.com/24946
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
codegod2222 added a commit to codegod2222/oauth_go that referenced this issue Nov 25, 2022
A change introduced in https://golang.org/cl/18692 expanded upon the errors
returned by the json package to be more informative about where the error occurred.
This breaks a test in oauth2 that relies on the exact form that an error takes.
Fix this test by simply checking whether it passes or not.

Fixes golang/go#17363
Updates golang/go#11811

Change-Id: I0062dc64fc1a8fd094b14ed1d0b21528edfbb282
Reviewed-on: https://go-review.googlesource.com/30600
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
@prattmic
Copy link
Member

prattmic commented Dec 7, 2022

Creating internal-branch.go1.20-vendor branches for the following repos:

arch 1bb480fc256a
crypto 2c476679df9a
mod 7c05a442b7c1 # v0.7.0
net 1e63c2f08a10
sync 8fcdb60fdcc0 # v0.1.0
sys 3ca3b18c8b9b # v0.3.0
term f72a2d8d642d # v0.2.0
text c8236a6712b1 # v0.5.0
tools 060c049c4674

@prattmic prattmic added the okay-after-rc1 Used by release team to mark a release-blocker issue as okay to resolve either before or after rc1 label Dec 7, 2022
@gopherbot gopherbot removed the okay-after-rc1 Used by release team to mark a release-blocker issue as okay to resolve either before or after rc1 label Dec 7, 2022
@mknyszek
Copy link
Contributor

Moving to 1.21.

@mknyszek mknyszek modified the milestones: Go1.20, Go1.21 Jan 30, 2023
@bcmills
Copy link
Contributor

bcmills commented Mar 1, 2023

The pkgsite-metrics repo is consistently failing on several builders (#58581), and has been for quite some time.

@prattmic
Copy link
Member

Creating internal-branch.go1.21-vendor branches for the following repos:

arch 40c19ba4a7c5 # v0.3.0
crypto 8e447d8cc585 # v0.10.0
mod 62c7e578f1a7
net f5464ddb689c
sync 93782cc822b6
sys 55b11dcdae81 # v0.9.0
term f6de4a13df88 # v0.9.0
text 2df65d769a9e
tools c6c983054920

@heschi heschi changed the title all: golang.org/x repos need to stay green all: user-facing golang.org/x repos need to stay green Jun 23, 2023
@cherrymui
Copy link
Member

Updated internal-branch.go1.21-vendor branches to the commits for latest merge into the main repo (as of
https://go.dev/cl/509099 )

arch	060bf14d30f8a6b2e19c8aab764c104725b1682f v0.4.0
crypto	2e82bdd1719d8f50d18bbb60acc52accc71330b1 v0.11.1-0.20230711161743-2e82bdd1719d
mod	baa5c2d058db25484c20d76985ba394e73176132 v0.12.0
net	57553cbff16307d5178b250ad301e7b466f9d969 v0.12.1-0.20230712162946-57553cbff163
sync	93782cc822b6b554cb7df40332fd010f0473cbc8 v0.3.0 // UNCHANGED
sys	a1a9c4b846b3a485ba94fede5b50579c7f432759 v0.10.0
term	edd9fb7f4aabf5aa4c7bca2146907778a2af0321 v0.10.0
text	e50348080f29449bcd6808c11400b3d45f08b09d v0.11.0
tool	1ca21856af7bffea38bd16dc62d9d31f4b6b5b86 v0.11.1-0.20230712164437-1ca21856af7b

@heschi
Copy link
Contributor

heschi commented Aug 4, 2023

Moving to 1.22.

@heschi heschi modified the milestones: Go1.21, Go1.22 Aug 4, 2023
BiiChris pushed a commit to BiiChris/crypto that referenced this issue Sep 15, 2023
Update golang/go#11811

The increased default concurrency in Go 1.5 showed up a test flake in
the TestHostKeyCert test. Under load, when the client provided incorrect
data, both sides would race to tear down the connection, which would often
lead to the server side, running in its own goroutine to see an unexpected
EOF or connection reset.

Fix this flake (and the incorrect use of t.Fatalf) by passing the error back
to the main goroutine for inspection. This also lets us ignore the expected
error in the unsuccessful path

Change-Id: I5a95c6d240479e9d537f34177e5ca8023b1b08e9
Reviewed-on: https://go-review.googlesource.com/12916
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@dmitshur
Copy link
Contributor

dmitshur commented Dec 1, 2023

Using-facing x/ repos seem green at this point, with one failure mode in x/tools that is being tracked in #64488.

@dmitshur dmitshur added the okay-after-rc1 Used by release team to mark a release-blocker issue as okay to resolve either before or after rc1 label Dec 1, 2023
@joedian joedian removed the okay-after-rc1 Used by release team to mark a release-blocker issue as okay to resolve either before or after rc1 label Dec 18, 2023
@mknyszek
Copy link
Contributor

mknyszek commented Feb 2, 2024

Looking over https://ci.chromium.org/ui/p/golang (currently hard to do for this task, the x-repo consoles should really be grouped by release; filed #65454), the user-facing x-repos appear to be green for the Go 1.22. Furthermore, the known issues pointed out by @bcmills are all fixed. (There are some infra failures on linux-riscv64 but this is a known issue. I was about to file an issue but it looks like the machine is online again, and passing tests for x-repos on Go 1.22: https://chromium-swarm.appspot.com/bot?id=linux-riscv64-mengzhuo.)

Moving this to Go 1.23.

@bcmills
Copy link
Contributor

bcmills commented Feb 6, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix The path to resolution is known, but the work has not been done. recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. release-blocker
Projects
Status: No status
Development

No branches or pull requests