Currently CI runs the extension/tools/generate.go -gopls command and checks if the package.json setting section and documentation generated from the package.json are consistent with the latest release of gopls (including prerelease).
As a result we end up our CI test fails whenever gopls is released, regardless of whether the change makes changes to a feature that depends on gopls. This adds unnecessary burden and noise to contributors.
I propose to remove this gopls setting test from CI.
However, since the extension currently doesn't pin the gopls version, it's still important to detect changes and breakage that may be caused by gopls release timely. We can have a separate workflow that runs against the prerelase version of gopls, creates a cl automatically, and also opens an issue if the extension misbehaves with the latest gopls.
Currently CI runs the
extension/tools/generate.go -goplscommand and checks if the package.json setting section and documentation generated from the package.json are consistent with the latest release of gopls (including prerelease). As a result we end up our CI test fails whenever gopls is released, regardless of whether the change makes changes to a feature that depends on gopls. This adds unnecessary burden and noise to contributors.I propose to remove this gopls setting test from CI.
However, since the extension currently doesn't pin the gopls version, it's still important to detect changes and breakage that may be caused by gopls release timely. We can have a separate workflow that runs against the prerelase version of gopls, creates a cl automatically, and also opens an issue if the extension misbehaves with the latest gopls.
cc @golang/tools-team