-
Notifications
You must be signed in to change notification settings - Fork 38.9k
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
containerized protobuf codegen does not handle .go-version / GOTOOLCHAIN properly #124932
Comments
/kind bug |
/triage accepted |
This is an error I've seen when we use Which is why what you said here makes sense: #124922 (comment). Once the actual bump happens, This seems to also be the reason the verify job failed here: #122410 |
I wonder if it would be a good idea to substitute the value of But I guess the long term solution would be to incorporate the toolchain directive into our go mods and the tooling. |
This also has the benefit of enabling IDEs to respect it without our makefiles (though your builds still won't match us if you just go build), but we gain additional complexity making these align and we need to continue to respect .go-version / envs properly for now because downstream users depend on this "API" |
Even if we switch to toolchain in go.mod we should probably make the env / .go-version work properly for at least one minor while putting a release note that downstreams must switch. (I'm sure an argument could be made for longer). It would probably be preferable to keep them working permanently because nobody wants to carry go.mod patches but it is common to need to force a different go version for security patching etc. |
Do we know yet if this applies to all branches? |
yes, it applies to all branches (we saw this when trying to just bump .go-version to 1.22.x on release branches) |
/assign |
So, interestingly if I do
Seems like something is broken with GOTOOLCHAIN support in this go install or go, rather than our scripts? |
Maybe something with the kube-build image. |
Normal go image:
kube-cross:
kube-build:
but under verify-codegen with
.... hmm |
narrowed it down to
|
Talked to @liggitt about this, who found even @ 765e7ef (just merged to master an hour ago) we can see:
So this is probably related. On master I think we can say this is already fixed @ HEAD and is just poorly behaved on the older branches. We should probably hack in a gimme fallback for this case on older branches while doing our best to respect |
Might not be worth prioritizing a patch given this is only relevant if you're:
This should be fine in 1.30+ * *well, there's a smaller bug in #125010 |
Thanks for digging here @BenTheElder! |
Hmm, this is slightly confusing, on darwin:
and with
I'm not sure why its with
|
Ah, |
Right, so for the newer branches where we have modules on and workspaces adopted, that just leaves #125010 We could try to mitigate this in the older branches ... but it's a fairly niche issue and the workspaces change is too large to backport so we'll have to write something custom for the old branches ... and you can already work around it by just overriding the build image to have the right go versoin. |
#125010 was fixed, so this should be OK for future branches. I want to iterate on the fix for #125010 and then backport to 1.30. We still have 1.28 / 1.29 for a while and should keep tracking this otherwise for now, but it's not clear that we have sufficient demand to invest in this further versus the involved workspace changes in 1.30+ |
Seen in #124922
Something is not working properly between .go-version → GOTOOLCHAIN when the go version inside this specific container doesn't match
/assign
/cc @BenTheElder @MadhavJivrajani
The text was updated successfully, but these errors were encountered: