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

x/tools/gopls: set up extended regtest CI #41865

Closed
findleyr opened this issue Oct 8, 2020 · 4 comments
Closed

x/tools/gopls: set up extended regtest CI #41865

findleyr opened this issue Oct 8, 2020 · 4 comments
Labels
gopls Issues related to the Go language server, gopls. Testing An issue that has been verified to require only test changes, not just a test failure. Tools This label describes issues relating to any tools in the x/tools repository.

Comments

@findleyr
Copy link
Contributor

findleyr commented Oct 8, 2020

In https://golang.org/cl/259137, I configured the regtests to only run in 'singleton' mode by default (communicating with the server via stdin/stdout).

This change was made because also running in 'forwarded' mode provides only fractionally more test coverage, and causes the tests to run more than 2x longer. Particularly on Darwin and Android builders, the regtests have gotten quite slow.

By running in parallel on Linux, the regtests can be made to run in <10s. We should set up extended CI (using Kokoro) to run the regtests in forwarded mode, and possibly even more modes: run with a separate daemon process, run with all experiments enabled, run in a nested module, etc.

This would achieve coverage of various execution modes without slowing down the builders.

CC @stamblerre

@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Oct 8, 2020
@gopherbot gopherbot added this to the Unreleased milestone Oct 8, 2020
@findleyr findleyr self-assigned this Oct 8, 2020
@bcmills
Copy link
Contributor

bcmills commented Oct 8, 2020

Would it make sense to condition the additional modes on !testing.Short() rather than a separate Kokoro workflow?

That way the Go project's longtest builders could provide coverage for them.

@findleyr
Copy link
Contributor Author

findleyr commented Oct 8, 2020

Would it make sense to condition the additional modes on !testing.Short() rather than a separate Kokoro workflow?

That's a good suggestion, thanks. I think that would probably be sufficient for now.

@stamblerre stamblerre modified the milestones: Unreleased, gopls/v1.0.0 Oct 9, 2020
@stamblerre stamblerre added this to In progress in vscode-go: gopls by default Nov 10, 2020
@findleyr findleyr moved this from In progress to Non-critical in vscode-go: gopls by default Nov 11, 2020
@stamblerre stamblerre added the Testing An issue that has been verified to require only test changes, not just a test failure. label Nov 24, 2020
@stamblerre
Copy link
Contributor

As part of this, we could possibly also run staticcheck and various other linters in Kokoro.

@stamblerre stamblerre moved this from Non-critical to Testing in vscode-go: gopls by default Jan 7, 2021
@stamblerre stamblerre removed this from Testing in vscode-go: gopls by default Jan 14, 2021
@stamblerre stamblerre added this to To Do in gopls on-deck Feb 28, 2021
@findleyr findleyr removed their assignment Dec 15, 2021
@findleyr
Copy link
Contributor Author

findleyr commented Sep 7, 2023

This was done a long time ago.

@findleyr findleyr closed this as completed Sep 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. Testing An issue that has been verified to require only test changes, not just a test failure. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
No open projects
Development

No branches or pull requests

4 participants