x/build/cmd/coordinator: write_go_bootstrap_tar failing with 404 on some arm builders #69038
Comments
cherrymui
added
the
NeedsInvestigation
|
cc @golang/release @dmitshur |
dmitshur
changed the title
dmitshur
added
NeedsFix
|
Change https://go.dev/cl/608076 mentions this issue: |
|
Thanks for reporting. This is a mistake in CL 520901, which didn't take into account the "-5" or "-7" suffixes in host config's Please note that the legacy build infrastructure isn't intended to be fully supported beyond the May 17, 2024 date (golang-dev thread), so we can only fix minor issues similar to this in order to help finish ongoing builder migrations to LUCI and give them more time. Thanks for for your work on migrating the remaining builders to LUCI. |
dmitshur
added
the
FixPending
The plan9-arm LUCI builder is pretty stable now, with no repeatable failures and no more intermittent flakes than the legacy version. Do I need to do something formal to switch off the legacy plan9-arm builder or just stop running it? |
|
Looks like the fix wasn't sufficient. All plan9-arm builds are now failing like this: I don't know why it's trying to load the bootstrap from |
Indeed, that is great! Both plan9/arm and plan/386 LUCI builders look good to remove their known issue and consider them added. I sent CL 608155 to do that, and CL 607656 to mark them as migrated. (CC @0intro.) When the coordinator is redeployed with the latter CL (next week), it'll stop sending work to the legacy plan9/arm builder. But given the equivalent LUCI builder is already providing good signal, I think it's fine for you to stop running it anytime. Thanks very much.
CL 606835 works around that go.dev/dl/ tarballs, where coordinator gets its go1.22.6 bootstrap toolchain from, have a top-level "go" directory by adding its bin directory to $PATH (or the equivalent From my side, it might be easiest to adjust the plan9-arm buildlet to set $GOROOT_BOOTSTRAP to $WORKDIR/go1.4/go. From your side, you could try to place a go1.22.6 plan9/arm bootstrap in |
dmitshur
removed
the
FixPending
I haven't heard from you on those CLs, so I'll put them on hold for now. Whenever you're ready to take those next steps, please let me know and I'll rebase & submit them. |
|
Closing this again since the original problem with write_go_bootstrap_tar failing with 404 is resolved, the only currently connected legacy plan9 builder (plan9-arm) is working okay with a go1.22.6 bootstrap, so I don't think there's more left to do here. |
Now I know why. The In the Plan 9 A better predicate, which will be true if the variable is undefined, an empty list, or an empty string, would be: |
|
Change https://go.dev/cl/627944 mentions this issue: |
The test "if(! ~ $#GOROOT_BOOTSTRAP 1)", to check for the environment variable GOROOT_BOOTSTRAP being undefined, will not succeed if the variable is set to the empty string (as the coordinator was doing). A better test is "if(~ $"GOROOT_BOOTSTRAP '')", which succeeds if the variable is undefined, or set to an empty list or an empty string. For #69038 Change-Id: Ic6e6944e0c76461daea206ba9575b863f92f6228 Reviewed-on: https://go-review.googlesource.com/c/go/+/627944 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David du Colombier <0intro@gmail.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Go version
gotip
Output of
go envin your module/workspace:What did you do?
Observed https://farmer.golang.org
What did you see happen?
What did you expect to see?
It appears the build script is trying to fetch boostrap archives of the form
go1.22.6.GOOS-arm-7.tar.gzwhen onlygo1.22.6.GOOS-arm.tar.gzexists (ie without the-7).The text was updated successfully, but these errors were encountered: