Description
Right now, the VSCode-Go repo integration test is testing against the last released version. (The definition of released is a version with a tag, both release version v0.17.1 and prerelease version v0.17.1-pre.1 are considered as released version). VSCode-Go test will prefer v0.17.1 over v0.17.1-pre.1 because v0.17.1 is an released patch version.
When doing feature implementation that involves change with client (vscode-go) and server (gopls), the integration test can not be added in the client side because the code implemented in the server is not released yet. So VSCode-Go have to rely on manual testing until the next gopls version (including the feature implementation merged) released.
The client side test coverage isn't ideal.
We should come up with a test that test vscode-go master branch with gopls's master branch so the client side could have test coverage even before the next gopls version released.
A few things that need to pay attention when implementing such test:
- When releasing gopls, the VSCode-Go need to sync the server capabilities by reading
gopls api-json
and convert the content topackage.json
. This need to be done before triggering the test otherwise the vscode-go won't be able to know some of the server's capabilities. So I think we can update the package.json only in test but not updating it through a commit to vscode-go (basically make some local changes to vscode-go repo without committing) - The test against last released version is still very important. We need to keep that test. So some of the test will only be triggered against gopls built from tip.
- The gopls built from tip does not have a version, or
dev
or a version that is useless. Keep that in mind when writing test.