feat: initial plugin startup and context management #278
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: this PR relies on #277 , and so that must be merged first.
This PR introduces the
plugin
module and some initial type definitions, as well as some code for turning aPlugin
into aPluginContext
object that will act as a wrapper interface for the gRPC channel (converting betweentonic
-generated types and "nicer" ones, maintaining the child process handle, etc.)`The logic for how startup occurs is a first try, and should be subject to discussion. Rather than a
MAX_CONN_ATTEMPTS
to handle syncronizing the plugin process andHipcheck
, I would support adding a requirement that the plugin outputs tostdout
some notifying message like "Ready." that we can wait for.The code of this PR compiles, but is untested. It would require defining an actual plugin, and injecting a way to test this code into
main.rs
. We may want to consider switching to a library-style crate so that we can have multiple differentbin/
files to enable easier testing of code such as this.