The gotip-linux-amd64_{c2s16,c3h88}-perf_vs_release builders are failing at tip due sweet running into an error building cockroachdb for baseline:

[sweet] error: build cockroachdb for baseline: exit status 1. stderr:
# github.com/cockroachdb/cockroach/pkg/util/goschedstats
../../util/goschedstats/runtime_go1.23.go:32:6: puintptr redeclared in this block
    ../../util/goschedstats/runtime_go1.20_21_22.go:24:6: other declaration of puintptr
../../util/goschedstats/runtime_go1.23.go:34:6: muintptr redeclared in this block
    ../../util/goschedstats/runtime_go1.20_21_22.go:26:6: other declaration of muintptr
../../util/goschedstats/runtime_go1.23.go:36:6: guintptr redeclared in this block
[...]
[sweet] error: failed to execute benchmarks, see log for details
2024/07/23 02:47:40 Error running sweet: error running sweet run: exit status 1
2024/07/23 02:47:40 FAIL
exit status 1

For example, see https://logs.chromium.org/logs/golang/buildbucket/cr-buildbucket/8741671757414064545/+/u/step/20/log/2.

There was an untested_go_version mechanism added a month ago in https://github.com/cockroachdb/cockroach/commit/e513328eb40954b91e2e9dc76d618468f4fee401 which may be relevant, since gotip represents the early development cycle of Go 1.24 now. Edit: CL 600196 already took that into account yesterday. (CC @aclements.)

CC @mknyszek, @dr2chase.

Comment From: gabyhelp

Related Issues and Documentation

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: mknyszek

This should be fixed by https://go.dev/cl/600196.

Comment From: mknyszek

No, sorry, it's still broken as of that CL, and I see now @dmitshur noticed that above.

Comment From: mknyszek

Ugh, I can't seem to reproduce the failure locally... This is making me think there's something specifically about the environment of the builder that's causing problems, or perhaps how cmd/bench is invoking sweet.

Comment From: dmitshur

@mknyszek Could the problem be that the baseline toolchain is something like 1.22 so the constraints in runtime_go1.20_21_22.go match, but because sweet now sets the untested_go_version tag, the constraint in runtime_go1.23.go also matches? This might be off, I looked only very briefly.

Comment From: aclements

I think you're right. Ideally, we'd fix this in CockroachDB upstream, but alternatively Sweet could be more careful to only set that build tag if it's actually on an unreleased version. I think the alternative is somewhat unstable in the long run, but it would work in the short run.

Comment From: gopherbot

Change https://go.dev/cl/600475 mentions this issue: sweet: apply flags to cockroachdb 'go build' based on 'go version'

Comment From: gopherbot

Change https://go.dev/cl/600495 mentions this issue: main.star: enable longtest builders on x/benchmarks for sweet