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

Open
findleyr opened this issue Oct 8, 2020 · 3 comments
Open

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

findleyr opened this issue Oct 8, 2020 · 3 comments
Labels
gopls Testing Tools

Comments

@findleyr
Copy link
Contributor

@findleyr 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 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
Member

@bcmills 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 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 removed this from the Unreleased milestone Oct 9, 2020
@stamblerre stamblerre added this to the gopls/v1.0.0 milestone 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 label Nov 24, 2020
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Nov 24, 2020

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

@stamblerre stamblerre removed this from the gopls/vscode-go milestone Dec 28, 2020
@stamblerre stamblerre added this to the gopls/v1.0.0 milestone Dec 28, 2020
@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 this from the gopls/on-deck milestone Dec 15, 2021
@findleyr findleyr added this to the gopls/unplanned milestone Dec 15, 2021
@findleyr findleyr removed their assignment Dec 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Testing Tools
Projects
No open projects
Development

No branches or pull requests

4 participants