feat(plugin): Add error augmentor plugin #118
Conversation
JesseTatasciore
force-pushed
the
jtatasciore/augment-error-message-content
branch
from
cb61d1e
to
3c5ba10
Compare
Co-authored-by: Thulio Ferraz Assis <3149049+f0rmiga@users.noreply.github.com>
Co-authored-by: Thulio Ferraz Assis <3149049+f0rmiga@users.noreply.github.com>
JesseTatasciore
force-pushed
the
jtatasciore/augment-error-message-content
branch
from
d7b26f8
to
a9861d0
Compare
Co-authored-by: Thulio Ferraz Assis <3149049+f0rmiga@users.noreply.github.com>
Co-authored-by: Thulio Ferraz Assis <3149049+f0rmiga@users.noreply.github.com>
… replacing regex groups
| @@ -14,6 +14,7 @@ import ( | |||
| // Plugin determines how an aspect Plugin should be implemented. | |||
| type Plugin interface { | |||
| BEPEventCallback(event *buildeventstream.BuildEvent) error | |||
| Setup(properties []byte) error | |||
There was a problem hiding this comment.
What do the bytes represent? Is it weird having bytes in the public API? Or is this not public?
There was a problem hiding this comment.
This is public. I have been thinking about this since yesterday, and I could be convinced to change the API here to take a map[string]interface{}. The disadvantage is that we limit the users from parsing the bytes straight into a typed struct.
There was a problem hiding this comment.
I do agree that its a little weird to have []byte on a public API like this. However it is the most convenient form for that data to be in. Makes it super easy for the plugin to parse it into its expected type. If we pass it through as something else then most plugins are just going to need to unmarshal it again creating extra work on their end
There was a problem hiding this comment.
Wire up SetupHook that will pass properties to their respective plugins
Add an error augmentor plugin that will parse bazel output and provide help
