cmd/dist: infer GO_TEST_TIMEOUT_SCALE? #19508
Comments
|
Sounds like a lot of pain and we'll still get bug reports about the value being wrong. I'd rather make sure such tests fail with loud but readable error messages telling them why it failed and that it's probably just their machine being slow. |
|
And what is the reason for the long work of the test? Do you examine these tests? Are there any computational tasks, math or parsing? Perhaps we should assume the maximum waiting time based on the slowest machine to current date? For example maximum time for 300 Mhz computer (like Pentium II)? I do not think that the testing time on such machines can be something limited, so you can specify quite large time intervals. Main reason is check compiler quality. In this case quality is prefer than time bounded. |
bradfitz
added
the
NeedsDecision
|
I don't see how to do this without causing more problems. Let's not do this. |
The timeout scale is currently set based on a hard-coded list of architectures. Perhaps we should instead run a typical task (perhaps a
go build) and estimate the appropriate timeout scale from how long it takes.There's no terribly good way to do this purely in cmd/dist, because starting the tests is a different invocation than bootstrapping, so we can't just reuse (say) the time it took to
go install std cmd; we'd have to do pointless work. We could do it in make.bash, although we'd have to replicate the logic to make.bat, make.rc, etc.@bradfitz opinions?
Related: #19484
The text was updated successfully, but these errors were encountered: