-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
switch build scripts to use go modules, stop requiring $GOPATH #82531
Comments
@liggitt The only way I found out to keep using go list without long build times was to run with |
I think @thockin was looking into running the command once and caching/reusing the results for the remainder of the |
I'd like to bring to attention that beginning with Go 1.13, the command go mod vendor will not include files tagged with |
That may be a side-effect of the fix for golang/go#29773, since it seems that you do have a lot of dependencies through older versions from the main module (due to heketi/heketi#1648). If the |
Hmm, maybe it wasn't that |
heketi/heketi issue resolved in heketi/heketi#1649, vendored copy bumped in #82805 |
The things that call go list have to be totally rewritten. |
compiling with 1.13 gives me:
At the bottom it calls |
...but the build fails later:
|
We use modules, golang1.13 (and bazel) in test-infra. The way we found to get the generators to work is to temporarily disable modules: https://github.com/kubernetes/test-infra/blob/master/hack/update-codegen.sh#L119 Here's how kind does the same thing without bazel's help: https://github.com/kubernetes-sigs/kind/blob/master/hack/update/generated.sh Does Are we sure we need to generate code for people on the fly? We could instead ask people to call go generate explicitly when they want to regenerate things. |
if we depend on people calling |
We can have presubmits catch this though, right? AKA a presubmit can regenerate and fail if anything changes. This is how test-infra handles things. We don't generate for people, but presubmits will fail if they forget:
It seems like go is pretty committed to making people use this pattern? It seems hard to reconcile doing anything else with the expectation that you can For example historically we generated protos on the fly with bazel, but it caused enough annoyance that we abandoned it in favor of an update-protos.sh (and verify-protos.sh) script and checking in the .pb.go files... Paradoxically people seem a lot happier since this change, despite the need to update manually. |
What a miserable experience, but I guess, maybe? |
That's where I ended up in https://github.com/liggitt/kubernetes/commits/go-1.13 as well |
The immediate motivation to get to go1.13 is for support reasons. Supported go versions last ~1 year, we're six months into go1.12, and we're about to ship k8s 1.16 and support it for ~9 months. My ideal scenario is to get a small set of changes in build/generation scripts we can pick to release-1.16 to get it into a go version supported for its lifetime. Long term, I'm hopeful the move to go1.13 and to using modules in build scripts will let us clean out a lot of GOPATH cruft we've accumulated, though I'd expect that cleanup to be more invasive and hopefully limited to k8s 1.17 only. |
looks like simply setting GO111MODULE=off in init.sh works around the build issues... that could be a reasonable first step to validate go1.13, and consider picking back to 1.16 (not urgently, just sometime in the next few months) |
/cc |
1.13.1 is now out |
@cblecker, note that 1.13.1 was a security release. The backports for performance regressions are slated for 1.13.2. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
xref: #105891 |
/milestone v1.24 |
Hi 👋 . Checking in from bug triage for 1.24. Should we be tracking progress on this issue for 1.24 release? |
Hi @liggitt 👋 . I'm checking in from bug triage team. Is this issue being targeted for 1.24 milestone? |
no, will move to 1.25. go1.18 added support for go workspaces, which might be helpful here (@thockin is carving up the make logic gradually, but that will not complete in 1.24) /milestone v1.25 |
Hopefully I can get more time soon so we can get this in for 25 |
Hi @liggitt |
I doubt it will be completed in 1.25, but some work is happening in the 1.25 timeframe (https://groups.google.com/a/kubernetes.io/g/dev/c/zcGFMru0gPU/m/h1OlbdBtAwAJ), so the milestone is still appropriate |
@liggitt 👋 the release 1.25 bug triage Lead. I'm reaching out to see the status of this Issue and if we are still targeting the current release. |
…n failure go 1.12 was removed from oe-core, but currently k8s cannot be built successfully with go 1.13. See link below. kubernetes/kubernetes#82531 We need to wait for k8s to support go 1.13 and update it to latest release, as well as its depedencies. Before this is done, add back go 1.12 and use it. Signed-off-by: Chen Qi <[email protected]> Signed-off-by: Bruce Ashfield <[email protected]>
…n failure go 1.12 was removed from oe-core, but currently k8s cannot be built successfully with go 1.13. See link below. kubernetes/kubernetes#82531 We need to wait for k8s to support go 1.13 and update it to latest release, as well as its depedencies. Before this is done, add back go 1.12 and use it. Signed-off-by: Chen Qi <[email protected]> Signed-off-by: Bruce Ashfield <[email protected]>
Tasks to move to go1.13:
Things that need to happen before $GOPATH support is dropped (potentially go1.18?):
go list
use in build scripts causing extremely long build times_output
$GOPATH setup from build code (build with modules+vendor)/cc @fejta @BenTheElder @cblecker
/sig release
The text was updated successfully, but these errors were encountered: