x/build: migrate to using Go modules #26872
Initially, I think we should start with exactly what we're doing today, but with the ability to make changes in x/build with a known-reasonable set of dependencies. That's https://golang.org/cl/128636.
There are certainly more interesting steps we can take down the road: for example, we might be able to use
This issue is for tracking those steps.
The text was updated successfully, but these errors were encountered:
I computed these using a build of the Go toolchain from a working copy at https://golang.org/cl/128136, patchset 12. The versions selected by 'go mod tidy' needed two tweaks to pass tests: go get golang.org/x/text@master go get github.com/russross/blackfriday@v1 The x/text version bump is because the last tagged version (v0.3.0) is very old (last December). The blackfriday bump is because the repository made a breaking change (v2.0.0) without changing the import path. With those changes, 'go test ./...' passes at the repo root. ('go test all' fails, possibly due to golang/go#26279.) Updates golang/go#26279. Updates golang/go#26872. Change-Id: Ieac5327e4bddd2b78b981d7683beb98608708a3a Reviewed-on: https://go-review.googlesource.com/128636 Reviewed-by: Brad Fitzpatrick <email@example.com>
Well, given this is x/build and its policy (which I can't find for some reason right now), we can experiment with modules as long as they work for our needs. See https://go-review.googlesource.com/c/build/+/128636/#message-82cc0747061a265a95ab44a9ef7debe6798a4392.
I'm in favor of using modules to build commands reproducibly for deployment (aka, replace what
As long as that doesn't interfere with keeping the libraries in this repo (e.g.,
First speed bump:
I suppose we could have one go.mod for all things in x/build but I'd prefer that each package main tool have its own, so we can bump dependencies independently as we deploy things.
Otherwise we'll be in a state where source code doesn't match deployed reality and we we'll bump go.mod deps affecting a dozen binaries and only deploy one of them, and have a few that haven't been deployed for years with untested deps.
What do I need to do to get past that error above, @bcmills?
If you're splitting out a submodule, the new submodule needs to depend on a version of the parent that does not contain the newly-split packages.
If you want to actually test that change, you'll probably need a
Also, along for the ride: * update from jessie to stretch * update from Go 1.10 to Go 1.12 * move to multi-stage Dockerfile, including drawterm, reducing image size * remove the static linking which was resulting in build warnings * clean up Makefile Updates golang/go#26872 Updates golang/go#27719 Change-Id: Ic4dc9b8539fb8662c9621c113fa94b70bc7de061 Reviewed-on: https://go-review.googlesource.com/c/build/+/175985 Reviewed-by: Dmitri Shuralyov <firstname.lastname@example.org>
…o modules Updates golang/go#26872 Updates golang/go#27719 Change-Id: I4de6d4f157b349911362e02b1781abd8b813f87a Reviewed-on: https://go-review.googlesource.com/c/build/+/176257 Reviewed-by: Dmitri Shuralyov <email@example.com>
Also, modernize the Dockerfile while I'm at it, using multi-stage builds more aggressively, and stop using gitlock (golang/go#26872) and switch to using Go modules to build the playground. (This also turns the playground into a module.) Updates golang/go#31944 Change-Id: Ic6f6152469f1930fd04180a3d1e63ed92ea2cfbd Reviewed-on: https://go-review.googlesource.com/c/playground/+/176317 Reviewed-by: Yury Smolsky <firstname.lastname@example.org>
Updates golang/go#26872 Change-Id: I7cf1bc512f7e4ab6592c1d645b95c7d135bd6c59 Reviewed-on: https://go-review.googlesource.com/c/build/+/176600 Reviewed-by: Dmitri Shuralyov <email@example.com>
Updates golang/go#26872 Change-Id: If64b03c03f29ccff2ffcf255d94a2c736806af89 Reviewed-on: https://go-review.googlesource.com/c/build/+/176602 Reviewed-by: Dmitri Shuralyov <firstname.lastname@example.org>
And update to multi-stage Dockerfiles, simplifying the build and making it more consistent with others. Updates golang/go#26872 Change-Id: If26e19d73c9bdb996343468cd1cff8edc574cb17 Reviewed-on: https://go-review.googlesource.com/c/build/+/176603 Reviewed-by: Dmitri Shuralyov <email@example.com>
This removes the last two gitlock users, so this also deletes gitlock. And update to multi-stage Dockerfiles, simplifying the build and making it more consistent with others. Updates golang/go#26872 Change-Id: I1e38c65eccfe9b8b7cb2d9acd6eb02aa33f8b877 Reviewed-on: https://go-review.googlesource.com/c/build/+/176604 Run-TryBot: Brad Fitzpatrick <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Andrew Bonventre <firstname.lastname@example.org>
The new x/website is built in module mode. Now that proxy.golang.org is available publicly, cmd/tip can start using it for fetching modules when building x/website. Also make a change to newServeMux so that httpsOnlyHandler is only used when HTTPS is turned on. That stops redirecting to HTTPS when HTTPS is not being served, thereby fixing HTTP-only local development mode. Updates golang/go#26872 Updates golang/go#30232 Updates golang/go#29206 Change-Id: If0382c45b9c99540adce3a894054730f5a7a9fdb Reviewed-on: https://go-review.googlesource.com/c/build/+/177217 Reviewed-by: Brad Fitzpatrick <email@example.com>
CL 176257 refactored the Dockerfile to remove the use of gitlock but I forgot to include ca-certificates here. Updates golang/go#32272 (fixes maybe) Updates golang/go#26872 Change-Id: I7b0e3a756bc9805e81e499b8b7d7c6ed0defb871 Reviewed-on: https://go-review.googlesource.com/c/build/+/179077 Reviewed-by: Dmitri Shuralyov <firstname.lastname@example.org>
This script was used when a custom gitlock tool was used for package management. That approach has been superseded with the switch to the module mode, and gitlock was deleted in CL 176604. By now, there are no directories with an update-deps make target remaining. For golang/go#26872. Change-Id: Ia7f5d9e8b277be55010d5752523d1160b72115b2 Reviewed-on: https://go-review.googlesource.com/c/build/+/227440 Reviewed-by: Brad Fitzpatrick <email@example.com> Reviewed-by: Carlos Amedee <firstname.lastname@example.org> Reviewed-by: Alexander Rakoczy <email@example.com> Run-TryBot: Alexander Rakoczy <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com>