Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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.
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 <firstname.lastname@example.org>
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 <email@example.com>
…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 <firstname.lastname@example.org>
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 <email@example.com>
Updates golang/go#26872 Change-Id: I7cf1bc512f7e4ab6592c1d645b95c7d135bd6c59 Reviewed-on: https://go-review.googlesource.com/c/build/+/176600 Reviewed-by: Dmitri Shuralyov <firstname.lastname@example.org>
Updates golang/go#26872 Change-Id: If64b03c03f29ccff2ffcf255d94a2c736806af89 Reviewed-on: https://go-review.googlesource.com/c/build/+/176602 Reviewed-by: Dmitri Shuralyov <email@example.com>
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 <firstname.lastname@example.org>
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 <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Andrew Bonventre <email@example.com>
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 <firstname.lastname@example.org>
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 <email@example.com>