The exp repository holds experimental and deprecated packages.
Don't test them on a very old version of macOS. There will be
macOS coverage with macOS 10.14.
Fixesgolang/go#34578
Change-Id: I9dde7202d26fdeb845378902ff5c077585536213
Reviewed-on: https://go-review.googlesource.com/c/build/+/197858
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The 'go install golang.org/x/website/cmd/golangorg' command is being
configured with GO111MODULE=on and GOPROXY=https://proxy.golang.org
environment variables, but its directory was not set. As a result,
the main module was an empty module (GOMOD=/dev/null) instead of
the module in the website repository that was just checked out.
Set the working directory of the go install command to websiteDir,
so that the intended website module is used during the build.
Fixesgolang/go#34545
Change-Id: If51030494ddb90a63b9d198209a04c5fb328784e
Reviewed-on: https://go-review.googlesource.com/c/build/+/197397
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Set the working directory in the Dockerfile to be inside the
golang.org/x/build module before running go install on cmd/tip.
Otherwise, it just installs the latest cmd/tip from the internet
rather than the intended local version. (All other Dockerfiles
in x/build had this line, except cmd/tip.)
Remove duplicate and unneeded WORKDIR instruction from two other
Dockerfiles to improve consistency.
Fix a rare race condition setting p.err when os.MkdirAll fails.
Add a log message when a new server has been started successfully
and the side switches. This will make logs easier to read.
Fixesgolang/go#34526
Updates golang/go#34192
Change-Id: Iab8124f5c872fb87844e8e2f9b31637ce395f11b
Reviewed-on: https://go-review.googlesource.com/c/build/+/197302
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Can optionally specify a prefix for gcsLogSegments when constructing
a GCSLog. This allows for a single bucket to be used with different
mutation logs scoped to "folders" by the prefix.
It should be noted that the notion of folders is arbitrary as in GCS, objects
are stored in a flat structure but can appear nested when combined with
unix-like paths.
Change-Id: Ia4b3c9d3b9dec7f1cca731f8546d80a64b1889b0
Reviewed-on: https://go-review.googlesource.com/c/build/+/193357
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
We're moving off of the Wiki and to committed markdown.
Change-Id: I931064bf42cc52d76f2044475a3c1df3edefc71e
Reviewed-on: https://go-review.googlesource.com/c/build/+/196697
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
By default, gopherstats generates stats for all go.googlesource.com Gerrit
projects, including the Go OSP, protobuf, and gopls. I'd like to restrict focus
to specific projects for use in perf artifacts.
Change-Id: I6ebfa9419386b852f3a24f25e92721be1b6fa6bb
Reviewed-on: https://go-review.googlesource.com/c/build/+/196257
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a cherry-pick of CL 135456 that restores Gerrit emails
for some people that were incorrectly changed in CL 165639, with
manual no-op addPerson line merges to address code review comments.
The cherry-pick applied very cleanly with just two minor merge
conflicts: one due to a Filippo's email already being fixed in
CL 176037, and another due to a close new entry.
Add tests to catch this from happening again, until the source
of the problem is resolved in issue golang/go#34259.
Updates golang/go#34259
Updates golang/go#28320
Updates golang/go#31919
Updates golang/go#27517
Updates golang/go#27631
Change-Id: Ia03a2b94403334d3f571ac5623e12d3bfd6f1e4f
Reviewed-on: https://go-review.googlesource.com/c/build/+/195062
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Don't auto-assign reviewers for CLs on shared branches such as
"dev.garbage" or "dev.ssa" -- the presumption is that folks working on
such branches will be familiar enough with development practices that
they can assign their own reviewers.
Change-Id: I196d73d76cb0c6e72dd30f52f9341febff311b7a
Reviewed-on: https://go-review.googlesource.com/c/build/+/196141
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The connection between linux-mipsle-mengzhuo and the build farm
is not stable and failed the snapshot upload stage, so we have to
skipsnapshot for that.
Updates golang/go#31217
Change-Id: Ic01620ec12254221f93234e8b25749a09f3dbc9c
Reviewed-on: https://go-review.googlesource.com/c/build/+/195977
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The h2demo command is an internal command that we use to
powers the https://http2.golang.org server, it is not a
package that others import.
It was never tested before golang.org/issue/34361 because it
had a +build h2demo constraint. But that build constraint is
being removed, so explicitly skip testing it in GOPATH mode.
The package is supported only in module mode now, since
it requires third-party dependencies.
Updates golang/go#34361
Change-Id: Ia3870baa10688b83f8400b1a5e13824a1c1b3d3b
Reviewed-on: https://go-review.googlesource.com/c/build/+/196097
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I've decided it's better not have a local replace directive checked
in to source control, because it makes the x/build module version
used by maintserve less predictable and less clear.
The go.mod file specifies x/build v0.0.0-20190313234014-6d820572de7c,
yet the local replace directive means the actual x/build version
is a moving target if someone builds maintserve inside this module.
However, if they build maintserve from another module that requires
this module, the replace directive wouldn't be used.
Make things simple and clear by removing the local replace directive.
If another version of x/build needs to be used during development of
maintserve, the go.mod file can be modified locally appropriately.
It doesn't need to be checked in.
Change-Id: I544e23e4fa4dfad53a9aa83467a7714011701701
Reviewed-on: https://go-review.googlesource.com/c/build/+/196018
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The code to fetch golang.org/x/* dependencies has become deeply nested
after additional logic and complexity has been added to runSubrepoTests,
making it harder to read, maintain, and be confident in. Factor it out
into a dedicated and well documented method.
This CL is a pure refactor. The next CL will make changes to simplify
the dependency fetching logic, which becomes easer after it has been
factored out.
Also factor out the code to concatenate multiple errors from
runSubrepoTests into a helper multiError type, and simplify
path.Join("go", "bin", "go") to a constant "go/bin/go".
Fixesgolang/go#34247
Change-Id: I4b5775408056723e2e5ab9a84776a11f5069d58a
Reviewed-on: https://go-review.googlesource.com/c/build/+/195277
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously, we were invoking a single 'go test' run at the repository
root with the import path pattern of 'golang.org/x/{repo}/...'. This
pattern does not match packages that are located in nested modules
in the repository.
Look for go.mod files in all subdirectories of the repository to find
all inner modules. Then, run 'go test' inside each module root, thus
testing all packages in all modules of the repository. If one of the
test invocations fails, keep testing others, and report all failures.
When looking for inner modules, consider only those that have module
path that would not be ignored by the go tool and aren't vendored.
This way, go.mod files inside testdata directories aren't treated as
if they're proper modules.
This is being done only when the tests are running in module mode,
since module boundaries don't exist in GOPATH mode.
Fixesgolang/go#32528
Change-Id: I9f8558982885c9955d3b34127c80c485d713b380
Reviewed-on: https://go-review.googlesource.com/c/build/+/194559
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a step towards improving the usability of this package.
Use myself as an example of the types of queries that GetPerson
accepts.
Updates golang/go#27631
Change-Id: I3f4d497eb237958c652e51e03fd2459f0f9df8ef
Reviewed-on: https://go-review.googlesource.com/c/build/+/195064
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also, because this is the first CL in this package to add tests, add a
helper to return the right template filename depending on the
environment (go test vs prod) so tests don't panic in init.
Fixesgolang/go#34097
Updates golang/go#34116
Change-Id: I4b3e83c2417611cfbdc32e27941dbb90687eb509
Reviewed-on: https://go-review.googlesource.com/c/build/+/194643
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This change adds controls to the dashboard package that makes it
possible to skip certain directories in subrepos from being tested
in GOPATH mode.
It uses this control mechanism to skip the gopls directory in x/tools
from being tested in GOPATH mode. That directory and everything inside
is developed with support for module mode only. All other packages
in x/tools continue to be supported both in module and GOPATH modes
for the current and previous releases, as per release policy¹.
¹ https://golang.org/doc/devel/release.html#policyFixesgolang/go#34190
Change-Id: Icdb4d0e1419f69c84c9a3f9a33727a09a35599f4
Reviewed-on: https://go-review.googlesource.com/c/build/+/194397
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These are the changes that have been pulled out of the previous CL to
keep it a more pure refactor.
The check for "same repo" is improved to handle the case of two repos
sharing a prefix (e.g., "golang.org/x/foo" and "golang.org/x/foobar").
The Dir field is set to repo root when invoking go list (it shouldn't
have an effect because it's currently done only in GOPATH mode). This
should make it more consistent with a future change that starts calling
go list in module mode for another purpose.
Create new repo variable instead of reusing repo parameter in findDeps.
Change-Id: Iba09fd2c4e9345e58ef885ce8ed4ba2acdfa3df7
Reviewed-on: https://go-review.googlesource.com/c/build/+/194359
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There are sufficient differences between the work we need to do
to test a subrepo in module mode and GOPATH mode, that it makes
sense to split it into two linear code paths. (I've tried keeping
it inline, but it led to less readable and harder to change code.)
This change is mostly a refactor with the intentional of not changing
any user-visible behavior. Behavior changes will follow in future CLs;
for now they're added as TODO comments.
The GOPATH mode path remains as before; minor improvements will be
applied in the following commit.
The module mode path is reduced to be empty at this time. The main
subrepo being tested is already fetched earlier, and its dependencies
don't need to be placed into a GOPATH workspace in module mode.
Change-Id: Ibfbe30b5d54ebe26cb5a783f0592f754fecfe53d
Reviewed-on: https://go-review.googlesource.com/c/build/+/194357
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
It will be necessary to know whether the current environment
and configuration has resulted in module mode or GOPATH mode
being selected. Do this dynamically by invoking 'go env GOMOD',
since the outcome depends on the version of Go and its default
GO111MODULE behavior, as well as whether a go.mod file is added
to the subrepo, and what environment overrides were applied by
coordinator via the BuildConfig.ModulesEnv method.
This requires the repository being tested to be available on disk,
so move the step of fetching it to happen earlier.
For now, this change only detects and logs the build mode.
Future changes will use this information further.
Updates golang/go#34190
Updates golang/go#32528
Updates golang/go#30233
Change-Id: I641becaaae5b6cfad22961d8864a877241e61cd3
Reviewed-on: https://go-review.googlesource.com/c/build/+/194277
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
There were a few places in releasebot that assumed the version
being made was a minor release (like go1.2.3) and didn't work
as expected for major releases (like go1.2). This change fixes
those, making releasebot suitable for creating major releases.
Computing the release branch and some of the error checking can
be factored out of doRelease to happen earlier. It's out of scope
for this CL, as it's better suited for a larger refactor later.
Fixesgolang/go#34045
Change-Id: Id2204d372043e1fd2afc699d39412677c603f034
Reviewed-on: https://go-review.googlesource.com/c/build/+/193018
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Currently the same as Emails[0], but the gophers package is the right
place to centralize that logic.
Change-Id: I6cc4fd36d76b94d7a4a49c36e3d5a30d6088850c
Reviewed-on: https://go-review.googlesource.com/c/build/+/192102
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Automatically label any issues with x/tools in the title. This will make
them easier to search.
Change-Id: Ib2b1b9d6b208d2c0748282a5cdeb8c7705483f61
Reviewed-on: https://go-review.googlesource.com/c/build/+/194360
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
And fix gitmirror's build due to missing internal/foreach.
Change-Id: I1a69b7f6680a7cc69947746dad2e5d4627a3122f
Reviewed-on: https://go-review.googlesource.com/c/build/+/194341
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Also updates the base image to Go 1.13 and removes the explicit
setting of GOPROXY as it’s not needed anymore in 1.13.
Change-Id: Ifa31fa2e7b1fb0f62f945c4dcea82900437dee85
Reviewed-on: https://go-review.googlesource.com/c/build/+/193878
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We specifically create a temporary GOPATH workspace in order to run
'go get golang.org/x/build/cmd/release' to install the release binary.
This was done with the intention to use GOPATH mode for the build.
Specify GO111MODULE=off explicitly so that GOPATH mode is always
used, regardless of local user configuration. This will produce
more consistent and reproducible results.
Installing the release binary in module mode is future work.
Fixesgolang/go#33031
Change-Id: I1df009432be3d0af4e5e7679f38d147901d950e7
Reviewed-on: https://go-review.googlesource.com/c/build/+/193720
Reviewed-by: Alexander Rakoczy <alex@golang.org>
These builders haven't existed for a while, and they consume
horizontal space on the build dashboard, pushing more interesting
columns off of the screen at moderate resolutions.
Updates golang/go#31217
Change-Id: Ib7021b699956d01d17e0ea8b213efd07b17d26f7
Reviewed-on: https://go-review.googlesource.com/c/build/+/193017
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The current behavior is very strict (one newline after the <p> tag
and no indentation before the release name). Relax these requirements
to only check for "<release name> (released ".
This makes it work for major releases in addition to minor releases.
Change-Id: I541a7d5959f0e00b8a8b471e9ce8440c6253bd3a
Reviewed-on: https://go-review.googlesource.com/c/build/+/193057
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Deploying in GOPATH mode is not supported, so explicitly specify
GO111MODULE=on to use module mode regardless of local setup.
Fixesgolang/go#34107
Change-Id: I5bc2518c4cd4c329eea65684fec96aae5b0bf808
GitHub-Last-Rev: 93f780cd58
GitHub-Pull-Request: golang/build#23
Reviewed-on: https://go-review.googlesource.com/c/build/+/193597
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Per release policy¹, we only support and test the two latest
major versions (currently Go 1.13 and Go 1.12).
Previously:
• CL 164218 removed Go 1.10.
• CL 133895 removed Go 1.9.
• CL 95555 removed Go 1.8.
• CL 77931 removed Go 1.7.
• CL 37466 removed Go 1.6.
• CL 31767 removed Go 1.5.
• CL 20843 removed Go 1.4.
¹ https://golang.org/doc/devel/release.html#policyFixesgolang/go#34096
Change-Id: I8ac7fcb6527e86706bdb7f140e3f05d3262f2476
Reviewed-on: https://go-review.googlesource.com/c/build/+/193477
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 180925 was a bit too aggressive. We've since cleaned up its changes
(see patchset 1 of this CL).
Updates golang/go#31788
Change-Id: I96b8fa4f5cbc158869e4f607aa69be130c0eda75
Reviewed-on: https://go-review.googlesource.com/c/build/+/193120
Reviewed-by: Ian Lance Taylor <iant@golang.org>
And because this uses new-in-Go1.13 http.Header.Clone, restrict all
the files to Go 1.13+ and bump the Dockerfile Go version.
Fixesgolang/go#33928
Change-Id: I147cc4465e393d2c34e59c70edf65f3901a5e132
Reviewed-on: https://go-review.googlesource.com/c/build/+/192341
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Starting October 1, App Engine will not allow apps using the 1.9
runtime to be deployed.
In module mode on go111 AppEngine, paths have changed to be relative to
the go.mod file.
More information can be found at
https://cloud.google.com/appengine/docs/standard/go111/go-differences
Change-Id: I3e291f20559ec8d3c5e8f51b756bd3b23b0c70bd
Reviewed-on: https://go-review.googlesource.com/c/build/+/192103
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Adding health checks at init is inflexible and earlier than neccessary.
It can cause problems for tests that run at the same time. It also
reduces code readability because it's harder to tell the relative order
of events during program initialization.
Instead, make it happen in main and inside relevant tests only.
Also pass a context through to help with cleaning up resources
after tests are done.
Updates golang/go#33949
Change-Id: Ib5ff6d93d200c273f2d344f6dd9179a7ad8e5db7
Reviewed-on: https://go-review.googlesource.com/c/build/+/192377
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
It's a good idea to have an allocation test for the foreachLine helpers
to ensure their zero-allocation property isn't accidentally compromised.
Such tests turned out not to be compatible with large packages that have
many existing high-level tests, some of which start HTTP servers and/or
clients and miscellenous goroutines, and in turn leak goroutines beyond
test execution that may cause allocations in the background, leading to
inaccurate reports from testing.AllocsPerRun.
In general, a best practice is to write tests that clean up all their
resources after completion, but cmd/coordinator is large and optimized
for a single execution. Future changes may be done in a way that will
cause TestForeachLineAllocs to fail intermittently again.
As a future-proof and simple solution, just factor out the foreachLine
helpers into a small, dedicated internal package.
Fixesgolang/go#33949
Change-Id: I664ec27f2b97c47a1cc88e5428152046187dbc36
Reviewed-on: https://go-review.googlesource.com/c/build/+/192680
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
CL 167638 made a change to add more CPU resources to the longtest
builder, with the intention of going from 4 vCPUs, 15 GB RAM to
16 vCPUs, 14.4 GB RAM.
It used n1-highcpu-8 GCE machine type, which actually has 8 vCPUs
and 7.2 GB RAM.¹ Having less RAM than before wasn't the intention.
Fix that by changing n1-highcpu-8 to n1-highcpu-16, which matches
the comment.
¹ https://cloud.google.com/compute/docs/machine-types
Updates golang/go#32831
Updates golang/go#33986
Updates golang/go#25886
Change-Id: I8426867fe33b3bf86576cb13d0d6113cd87f30c1
Reviewed-on: https://go-review.googlesource.com/c/build/+/192679
Reviewed-by: Bryan C. Mills <bcmills@google.com>
CL 190998 broke the nacl-386 builder, but nacl support is being
dropped as of Go 1.14 anyway.
Updates golang/go#30439
Change-Id: If9a7ea1230d4af0a127aeb14005063be4092cf84
Reviewed-on: https://go-review.googlesource.com/c/build/+/192537
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Andrew Bonventre
Dmitri Shuralyov
Brad Fitzpatrick
yuval
Colin Nelson
Rebecca Stambler
Yury Smolsky
Sameer Ajmani
Matthew Dempsky
Than McIntosh
Meng Zhuo
Benny Siegert
Filippo Valsorda
smasher164
Bryan C. Mills
Alexander Rakoczy