-
Notifications
You must be signed in to change notification settings - Fork 17.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
x/build/cmd/release: windows-amd64 release process is failing on tip due to unexpected stale targets after second build #52009
Comments
As expected, running I suspect that it is something to do with the environment or args passed to the scripts. I'm adding some logging to |
Change https://go.dev/cl/398059 mentions this issue: |
Change https://go.dev/cl/398060 mentions this issue: |
Change https://go.dev/cl/398058 mentions this issue: |
Change https://go.dev/cl/398061 mentions this issue: |
I did eventually reproduce this by setting |
These fields have been parsed as quoted fields since CL 334732, but we missed the unparsing side in 'go env'. Certain scripts (notably make.ba{sh,t}) expect to be able to set the environment to exactly what 'go env' reports, so for round-trip purposes it is important to match the marshaling and unmarshaling functions. (Noticed while debugging #52009.) Updates #41400 Change-Id: I0ff39b7a6e1328111c285c97cd23f79b723f3c73 Reviewed-on: https://go-review.googlesource.com/c/go/+/398058 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cache keys are dumped in case of mismatch; an empty modinfo string adds noise to that dump without a corresponding benefit. For #52009. Change-Id: I1b4cd85fa5ff920973552fc94977954f93622a32 Reviewed-on: https://go-review.googlesource.com/c/go/+/398059 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/dist may set and/or unset variables before building, and at any rate it is fragile to run 'go install' before sourcing env.bat. The build-stamp information embedded by the 'go' command is currently sensitive to whether CGO_* variables are implicit or explicit, so running 'go install' before env.bat may cause stamped metadata to become stale. (Explicitly setting to the default arguably ought to produce the same metadata as leaving the variables unset, but that's a separate issue and a bigger cleanup.) Moreover, run.bat is supposed to parallel run.bash, and run.bash already hasn't invoked 'go install' itself since CL 6531! For #52009 Change-Id: Ie35217913f02cc7e0c3f9b12874abd7416473478 Reviewed-on: https://go-review.googlesource.com/c/go/+/398060 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
As detected early by @heschi via work on #51797, Go 1.19 tip tree that will be used during the release process is not passing on the
windows/amd64
release target.Bisection shows the problem starts with CL 391809 (CC @bcmills). Either there's a problem in that CL that is uncovered only during the sequence of steps the current release process performs (since it's not being caught by builders), or there's a problem with that sequence which is only being uncovered by that change.
Its parent commit (d68615f) gets as far as API check successfully, but commit 0433f57 fails early in the "Building (all.bash to ensure tests pass)" step with:
(complete log https://gist.github.com/dmitshur/80444d6afa37edb6dcdc2f2979545762)
This test failure can be reproduced with cmd/release (can only be done by someone with gomote access).
CC @golang/release.
The text was updated successfully, but these errors were encountered: