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

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

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

rsc opened this issue Jul 21, 2015 · 64 comments

Comments

@rsc
Copy link
Contributor

@rsc rsc commented Jul 21, 2015

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

@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

@gopherbot gopherbot commented Jul 29, 2015

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 29, 2015

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

@gopherbot gopherbot commented Jul 29, 2015

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 29, 2015

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

alandonovan added 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

@gopherbot gopherbot commented Jul 30, 2015

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 31, 2015

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

@gopherbot gopherbot commented Jul 31, 2015

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 31, 2015

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

@gopherbot gopherbot commented Aug 1, 2015

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

@gopherbot gopherbot commented Aug 5, 2015

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

@gopherbot gopherbot commented Aug 6, 2015

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>
gopherbot pushed a commit to golang/tools that referenced this issue Jan 2, 2020
The generated static.go file was missing a license header when it was
created in 2013 in CL 12805046. CL 38165 added a license header, using
the current year in the template. This causes the static.go file to go
"out of date" whenever the year changes.

Change the copyright year to be a fixed year when the file was created.
This way, the TestStaticIsUpToDate test will stop breaking every year.

Updates golang/go#36360
Updates golang/go#11811

Change-Id: If1597b0d93b7eacf23b7de103a6d7e3ca049bb4f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/213119
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Jan 2, 2020

Change https://golang.org/cl/213121 mentions this issue: content/static: generate constant 2019 copyright year

gopherbot pushed a commit to golang/website that referenced this issue Jan 2, 2020
The generated static.go file was created in 2019 in CL 156321, and
it inherited the generator code from x/tools that uses today's year.
There isn't a need to update the copyright year, so make it a constant.

This change fixes the failing TestStaticIsUpToDate test in 2020,
and prevents it from breaking in every future year.

Fixes golang/go#36360
Updates golang/go#11811

Change-Id: Ie87b1219448f1e288539f95280492b4f95b76798
Reviewed-on: https://go-review.googlesource.com/c/website/+/213121
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Jan 17, 2020

Change https://golang.org/cl/215299 mentions this issue: kubernetes/gke: skip 4 tests on builders

gopherbot pushed a commit to golang/build that referenced this issue Jan 17, 2020
The current GKE tests require to be run on GCE and with Application
Default Credentials that have at least the container.clusters.list
permission, at least one GKE cluster, and possibly more.

The builders that run these tests don't have sufficient permissions,
which means these tests never pass. Skip these tests, they can be
re-enabled if/when we decide they're worth running automatically and
make it possible to do so. Until then, they can be run manually.

Updates golang/go#28543
Updates golang/go#11811

Change-Id: Ib76f9d4f93ece2b922c099a21dec4ceefb45b546
Reviewed-on: https://go-review.googlesource.com/c/build/+/215299
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@cagedmantis
Copy link
Contributor

@cagedmantis cagedmantis commented Feb 4, 2020

@dmitshur and I have verrified that the subrepos are green for the release branches of golang.org/x repos that are used in the cmd and std modules:

cmd
github.com/google/pprof v0.0.0-20191105193234-27840fff0d09
github.com/ianlancetaylor/demangle v0.0.0-20180524225900-fc6590592b44
golang.org/x/arch v0.0.0-20190815191158-8a70ba74b3a1
golang.org/x/crypto v0.0.0-20200128174031-69ecbb4d6d5d
golang.org/x/mod v0.2.0
golang.org/x/net v0.0.0-20190620200207-3b0461eec859
golang.org/x/sync v0.0.0-20190423024810-112230192c58
golang.org/x/sys v0.0.0-20200131233351-9e5cf931a04b
golang.org/x/text v0.3.0
golang.org/x/tools v0.0.0-20200131233409-575de47986ce
golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898
rsc.io/pdf v0.1.1
std
golang.org/x/crypto v0.0.0-20200128174031-69ecbb4d6d5d
golang.org/x/net v0.0.0-20191126235420-ef20fe5d7933
golang.org/x/sys v0.0.0-20200201011859-915c9c3d4ccf
golang.org/x/text v0.3.3-0.20191031172631-4b67af870c6f
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e

We are considering the sub repos to be green for the purposes of cutting the go1.14rc1.

@dmitshur
Copy link
Member

@dmitshur dmitshur commented Feb 21, 2020

This task has been completed for the Go 1.14 cycle at the time of cutting the go1.14rc1 release, see above comment for details.

Moving this issue to the Go 1.15 milestone.

@dmitshur dmitshur modified the milestones: Go1.14, Go1.15 Feb 21, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Apr 6, 2020

Change https://golang.org/cl/227379 mentions this issue: dashboard, app/appengine: set a known issue for staticlockranking builder

gopherbot pushed a commit to golang/build that referenced this issue Apr 7, 2020
…lder

The linux-amd64-staticlockranking builder was added pre-emptively so
that it could be tested and used during the development of a CL that
implements a new feature. It's expected to fail until that work is
completed. Mark it as a builder with a known issue, golang/go#38029.

The new BuildConfig.KnownIssue field can be used by builders being
added in the future so that if they fail at first, it doesn't take
away time for people looking at build.golang.org, which we always
aim to have as green as possible¹.

¹ https://groups.google.com/d/msg/golang-dev/y0yM_Xi665Q/hUpBiUPiCAAJ

Fixes golang/go#38283
For golang/go#38029
For golang/go#37937
For golang/go#11811

Change-Id: Iba1606c7021ffa7e67ddbaae2fc6b65f4e46ab34
Reviewed-on: https://go-review.googlesource.com/c/build/+/227379
Reviewed-by: Alexander Rakoczy <alex@golang.org>
@dmitshur dmitshur changed the title all: subrepos need to be green all: subrepos need to stay green May 21, 2020
@dmitshur dmitshur changed the title all: subrepos need to stay green all: golang.org/x repos need to stay green Jun 2, 2020
@dmitshur
Copy link
Member

@dmitshur dmitshur commented Jun 2, 2020

image

The golang.org/x repos are green for first-class ports at this time.

The only failures are in x/build (#36163), and x/mobile and x/exp (#39156), none of which contribute packages to the main Go distribution.

The golang.org/x repos need to continue to stay green for the rest of 1.15 release cycle, but this isn't blocking the Go 1.15 Beta 1 release.

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 1, 2020

Change https://golang.org/cl/240512 mentions this issue: dashboard: stop linux-386-longtest builds in x/exp and x/mobile

gopherbot pushed a commit to golang/build that referenced this issue Jul 1, 2020
Both golang.org/x/exp and golang.org/x/mobile are experimental,
and do not support the linux/386 port. Stop running post-submit
longtest builds on it. If support for linux/386 is added, tests
should start to pass and the builder can be re-enabled then.

It appears to have been enabled previously due to a misconfiguration
rather than on purpose.

Fixes golang/go#39156.
For golang/go#29641.
For golang/go#11811.

Change-Id: I12437880380b9015f6ed9d584db11717f4f024e6
Reviewed-on: https://go-review.googlesource.com/c/build/+/240512
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
@toothrot
Copy link
Contributor

@toothrot toothrot commented Jul 24, 2020

Creating release branches for Go 1.15 RC1:

# golang.org/x/arch v0.0.0-20200511175325-f7c78586839d
# golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9
# golang.org/x/mod v0.3.0
# golang.org/x/net v0.0.0-20200707034311-ab3426394381
# golang.org/x/sys v0.0.0-20200501145240-bc7a7d42d5c3
# golang.org/x/text v0.3.3-0.20200430171850-afb9336c4530
# golang.org/x/tools v0.0.0-20200616133436-c1934b75d054
# golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.