Add support for running remote check plugins #3524
Conversation
This PR adds support for invoking of remote Wasm plugins locally. Remote plugins Refs are resolved using the buf.lock file in the input's v2 workspace.
|
The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).
|
private/buf/bufctl/controller.go
Outdated
| // GetCheckRunnerProvider gets a CheckRunnerProvider for the given input. | ||
| // | ||
| // The returned RunnerProvider will be able to run lint and breaking checks | ||
| // using the PluginConfigs declared in the input buf.yaml. The input | ||
| // provided will resolve to a Workspace, and the remote PluginConfigs | ||
| // Refs will be resolved to the PluginKeys from the buf.lock file. |
There was a problem hiding this comment.
I think we should not need to resolve the input to a workspace for GetCheckRunnerProvider.
The first use-case, for buf {lint, breaking}, we are already building the target set of []ImageWithConfigs, we should return the requisite CheckRunnerProvider with it, since it already builds the workspace. It also allows us to not duplicate the logic for the various input refs.
For the LSP use-case, we are calling it in FindModule, which provides the workspace.
For the ls-{lint, breaking}-rules use-case, we have avoided building the workspace thus far, but we may need to call GetWorkspace and refactor the logic accordingly. We already have access to the controller.
I think instead of a generic GetCheckRunnerProvider at the top-level of the controller, we should instead have GetTargetImageWithConfigs now also return the CheckRunnerProvider and then add a function that is something like GetCheckRunnerProviderForWorkspace that gets the check runner provider for a given workspace.
There was a problem hiding this comment.
Refactored GetCheckRunnerProvider to return the image with configs and a bufcheck.RunnerProvider. For cases where a config override is present we now resolve plugins with the BSR. For other cases, where the default config dir path is used the workspace is always attempted to be loaded. The workspace now provides the PluginKeys, which are used to create a static set for the PluginKeyProvider. Going through testing of the various inputs.
| @@ -321,6 +322,7 @@ func testNewWorkspaceProvider(t *testing.T, testModuleDatas ...bufmoduletesting. | |||
| bsrProvider, | |||
| bsrProvider, | |||
| bsrProvider, | |||
| bufplugin.NopPluginKeyProvider, | |||
There was a problem hiding this comment.
I think we could address this in a follow-up PR, or it might give us a little more confidence here, but we may want to implement something similar to the bufmoduletesting.OmniProvider stubs.
private/buf/buflsp/file.go
Outdated
| @@ -371,6 +372,24 @@ func (f *file) FindModule(ctx context.Context) { | |||
| return | |||
| } | |||
|
|
|||
| // Get the check runner provider for this file. The client is scoped to | |||
| // the inputs buf.lock file, so we need to get the check runner provider | |||
| // for the workspace that contains this file. | |||
There was a problem hiding this comment.
The LSP is currently supported but in testing it can result in a large number of queued checks causing the LSP state to lag behind the editor. It looks like each file change causes a lint command to be executed. As each lint is slower then the number of changes in the file many false annotations are provided before the current file state is reached. This is exaggerated with Wasm plugins as they are slower then native.
emcfarlane
force-pushed
the
ed/pluginInokeRemote
branch
from
f5c9529 to
457ca75
Compare
This PR adds support for running remote check plugins in
buf lintandbuf breakingcommands. These plugins are specified as references (<remote/owner/plugin>) in thebuf.yamlfile and must be pinned to specific versions in thebuf.lockfile.To pin plugin versions, users can run
buf plugin updatecommand, which updates thebuf.lockfile with the necessary metadata to resolve the plugin version when run. If a plugin reference inbuf.yamlis not pinned in thebuf.lockan error is returned prompting the user to pin the plugin version by runningbuf plugin update. This allows for running checks offline and avoids network access when all plugin data is cached.Arguments can be provided to both local and remote plugins by specifying any space separated commands after the path or reference (e.g.
buf.build/myorg/myplugin --debug). These args are passed as command line arguments on every run.