Skip to content
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

cmd/dist: infer GO_TEST_TIMEOUT_SCALE? #19508

Closed
josharian opened this issue Mar 11, 2017 · 3 comments
Closed

cmd/dist: infer GO_TEST_TIMEOUT_SCALE? #19508

josharian opened this issue Mar 11, 2017 · 3 comments

Comments

@josharian
Copy link
Contributor

@josharian josharian commented Mar 11, 2017

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

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Mar 21, 2017

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.

@bradfitz bradfitz added this to the Go1.9Maybe milestone Mar 21, 2017
@vit1251
Copy link

@vit1251 vit1251 commented Mar 21, 2017

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 bradfitz modified the milestones: Go1.10, Go1.9Maybe Jun 28, 2017
@rsc
Copy link
Contributor

@rsc rsc commented Nov 29, 2017

I don't see how to do this without causing more problems. Let's not do this.

@rsc rsc closed this Nov 29, 2017
@golang golang locked and limited conversation to collaborators Nov 29, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.