cc @golang/release

The race detector builders currently have GO_DISABLE_OUTBOUND_NETWORK=1 while longtest builders have needsGoProxy: true. These seem in conflict, and I don't have a good idea of how they'll actually resolve. I guess I can just try and see what happens?

The long tests require network so you'll want to leave the network enabled.

Got it. Also @bcmills do you want this to run for subrepos? Or are you just concerned about the main repo at the moment?

(I figure I'll just start with the main repo since I suspect there will be some surprises...)

Ideally subrepos too (especially x/sys and x/net), but the main repo is a good starting point.

I redeployed the coordinator and the builders are online! (For subrepos as well.) Hopefully the timeout scale is sufficient. We'll see soon.

I think the UI could also use some work. It's in the race section but it just says "linux" twice. I'll poke at that.

Change https://go.dev/cl/449196 mentions this issue: dashboard: add linux-amd64-longtest-race builder

Hm, the builds seem stuck on... what I have to guess is the index/suffixarray tests. On longtest those already take 47 seconds... I wonder if it's ballooning out on longtest x race.

For comparison, image/gif longtest seems to be around 6x slower with the race detector. So, assuming that slowdown applies here as well (maybe not) 47 seconds balloons out to around 5 minutes. That seems like a lot.

Worse than that actually, 600+ seconds. The runtime tests took 700+ seconds. Unfortunately the builds are incredibly slow. :( How should we proceed? Leave the builder but start disabling tests for this configuration? Is it fine to be this slow?

Reference: https://farmer.golang.org/temporarylogs?name=linux-amd64-longtest-race&rev=d2aa787f2a925a97dad11b1acb2a065f52b097f8&st=0xc000fb7dc0

If the tests pass reliably (with an appropriate timeout scale factor), then I guess the relevant question is just how slow are they?

Given that the race detector dumps exact stack traces for any race it detects, and given that it's for a common platform and architecture (so not hard to find a local machine to run the tests on), I'd say that if the builder takes, say, twice as long as the longtest builder overall, that's probably fine. But if it's going to take, say, 10 hours per run, we probably ought to prune things back in some way.

The log you linked seems to have disappeared, but looking at the index/suffixarray tests it looks like they're running exhaustive checks over huge input spaces (2²¹ and 3¹⁴ cases, respectively). Given that those spaces have already been checked exhaustively, I wonder if those tests would be more cost-effective as fuzz tests sampling fewer elements, perhaps from an even larger space. 🤔

It's definitely not 10 hours but I don't have complete data. It does actually seem to be mostly keeping up with tip, so maybe it's fine.

Maybe let's just leave it up and we can work on improving run times more incrementally.

It does look like x/tools/go/pointer and x/benchmarks/sweet/cmd/sweet might need either some test skips or a longer timeout scale. I see consistent timeouts in those.

x/benchmarks/sweet/cmd/sweet is just one test and yeah, it should probably just be disabled for this builder.

Change https://go.dev/cl/449518 mentions this issue: go/pointer: break TestInput into subtests and update skips