-
Notifications
You must be signed in to change notification settings - Fork 126
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
feat: experimental plugin setup #269
Conversation
100e337
to
33b96cd
Compare
Quickly reviewed the code, I like the solution . I'd be curious to see the implementation of a simple hello world plugin, and it seems that you just need one line to invoke a certain function (with a standard signature) to close the loop, if I'm not mistaken. At that point we should already have a working solution for modularity at application level. |
As part of this PR, I intend to create a trivial example plugin which the In terms of how plugins should expose their functionality, defining it via a function is fine as a first draft. However, I anticipate this can much more complex if we want to start modularizing specific layers such as the database/persistence, audit logs or events and different server types (HTTPS, SSH, email via #61). A single callable function can work for trivial use cases (particularly around checking commit information against a list of "good values" such as repo names, authors, etc). For the purposes of externalizing the static configuration-based checks (resources/config.json) and providing an OPA option via #99 , we can stick with a simple request/response function that a plugin author can pass in. I do think we want to provide much more facilities for custom behaviour within git-proxy but we can iterate on that. |
33b96cd
to
f252a6d
Compare
This comment was marked as outdated.
This comment was marked as outdated.
6024ac6
to
cc4321c
Compare
@JamieSlome I had to bump the nodejs workflow to Node 16.x as an FYI - adding this new dependency requires >= 14 @maoo working "hello world" example plugin as of c381bc5 : App startup
on push, plugin executes
the remaining steps (
|
@coopernetes - great PR 🎉 The Node bump should be fine, checks and tests are passing 👍 I have reviewed the code and as a first estimation, this is great. As you mention in your code, we can re-think the entry/loading point of the functions into the "chain". I still need to play around with the code by running this locally, but from your proof of concept above this looks easy enough. I don't think we need to strive for perfection on how the plugin manager works, so long as it gives us enough room for extensibility and modularity, i.e. expose custom (user-defined) and pre-defined (official/recommended) plugins to the "chain". We can always look to improve the sophistication later on. |
src/plugin.js
Outdated
localPlugins = localPlugins.concat(p); | ||
} else { | ||
packagePlugins = packagePlugins.concat(p); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: simply push a new item into the plugin list instead of concat.
localPlugins = localPlugins.concat(p); | |
} else { | |
packagePlugins = packagePlugins.concat(p); | |
localPlugins.push(p); | |
} else { | |
packagePlugins.push(p); |
c381bc5
to
4c0d0ba
Compare
* add Dockerfile & entrypoint script for container deployments
* on proxy startup, read plugin names via environment variable `GITPROXY_LOAD_PLUGINS` as a comma-separated list * on startup, initialize PluginManager which sets a list of plugins and loads them via `load-plugin`. Note, this is a no-op atm since the actual proxy processors are not calling into plugin functions yet * add lerna to support multiple npm packages in a single workspace. This is necessary to start breaking apart the monolithic git-proxy package code into separate packages. * add HttpPlugin class which takes in a request & response function. This class should implement those methods. Note, this is better suited to TypeScript which has built-in interfaces. This doesn't "do" anything yet. feat: plugin system re-ordered hardcoded values work in progress
- fixed bug with async execution of PluginManager initialization. Plugins by name or package are first resolved & loaded then we do the ProxyPlugin object casting once those run to completion via a Promise.all()
- remove list of Node module objects (this.pluginModules) in PluginManager. It's never used outside of loadPlugins() so its fine to convert to a local var
- pluginManager.plugins was capturing a nested Array ([][]ProxyPlugin) so fixed that up. - working through a bug in parsePackFile action
- upgrade nodejs workflow to 16.x. New dependencies won't build on <14 - pass in the ActionPlugin.exec function as part of the proxy chain - update JSDoc on ActionPlugin - add test for creating the PluginLoader
4c0d0ba
to
157a24a
Compare
Test coverage isn't complete and some of the bits in the PluginLoader (renamed from PluginManager) would be pretty difficult to test since we're dynamically bringing in Node modules directly. Some additional JSDoc notes added and I've removed the hard-coded plugin that would be loaded on startup so that plugins are "opt-in" via the PluginLoader isn't invoked
PluginLoader running with "hello world" example
Ready to merge as a prototype. |
- closing in favour of finos#282
- unused lerna config deleted. This would be re-added only if Lerna is the tool of choice and when refactoring the existing src into discreet packages & workspaces
@coopernetes - fabulous work! 🎉 Thanks for including some tests. I'll have a play around with the code at some point today but generally looks good to merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🍰
This is huge! Thanks @coopernetes ! |
feat: experimental plugin setup
feat: experimental plugin setup
This is a working PR for adding experimental plugin support to git-proxy.
Related #47
Misc: