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

Update bufcheck.RunnerProvider to use the plugin config #3328

Merged
merged 3 commits into from
Sep 18, 2024

Conversation

emcfarlane
Copy link
Contributor

Update bufcheck.RunnerProvider to take the bufconfig.PluginConfig as the argument for creating the runner. This allows for setting the runner not based on the the local path config. A helper has been provided to create local runners for a command.Runner.

Changes bufcheck.RunnerProvider to take the bufconfig.PluginConfig as
the argurment for creating the runner. This allows for setting the
runner based on configuration other than the plugin path. A helper has
been provided to create local runners for a command.Runner.
Copy link
Contributor

github-actions bot commented Sep 18, 2024

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed✅ passedSep 18, 2024, 8:40 PM

}

// NewRunnerProvider returns a new RunnerProvider for the command.Runner.
func NewRunnerProvider(delegate command.Runner) RunnerProvider {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid import of bufconfig in a pkg dir this has been moved to bufcheck.

@@ -331,21 +331,17 @@ func (c *client) getMultiClient(
)
}
for _, pluginConfig := range pluginConfigs {
if pluginConfig.Type() != bufconfig.PluginConfigTypeLocal {
return nil, syserror.New("we only handle local plugins for now with lint and breaking")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Error message is moved to the runner provider.

annotations := slicesext.Map(
delegateResponse.Annotations(),
func(checkAnnotation check.Annotation) *annotation {
return newAnnotation(checkAnnotation, delegate.PluginName)
},
)
lock.Lock()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated change, looks like we can move the lock to wrap just the append.

type RunnerProvider interface {
NewRunner(programName string, programArgs ...string) pluginrpc.Runner
NewRunner(pluginConfig bufconfig.PluginConfig) (pluginrpc.Runner, error)
Copy link
Member

@mfridman mfridman Sep 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is the primary motivation of this PR, otherwise, this interface is tightly coupled to executing local binaries command exec style. Specifically here:

c.runnerProvider.NewRunner(
// We know that Path is of at least length 1.
pluginPath[0],
pluginPath[1:]...,
),

By taking a PluginConfig, we can have constructors for various configs like NewLocalPluginConfig and NewRemotePluginConfig NewLocalWASMPluginConfig (bad name, but something to differentiate).

This lifts the pluginConfig.Type() != bufconfig.PluginConfigTypeLocal check to the NewRunnerProvider constructor. The provider now has more information about what the RunnerProvider should be.

I think it'd be awesome if in the end state, we had a common runner provider interface that could support:

  1. executing local binaries
  2. executing compiled WASM modules (this would be super handy for testing, although you could argue option 1 is good enough)
  3. executing WASM modules downloaded from the BSR locally

@bufdev bufdev merged commit 411778b into main Sep 18, 2024
11 checks passed
@bufdev bufdev deleted the ed/bufcheckRunnerProviderConfig branch September 18, 2024 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants