Plugin Support #110
Plugin Support #110
Conversation
eternal-flame-AD
force-pushed
the
plugin
branch
from
c7cb799
to
ff77c4e
Compare
Codecov Report
@@ Coverage Diff @@
## master #110 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 26 27 +1
Lines 806 822 +16
=====================================
+ Hits 806 822 +16
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #110 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 26 27 +1
Lines 806 822 +16
=====================================
+ Hits 806 822 +16
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #110 +/- ##
======================================
Coverage 100% 100%
======================================
Files 27 39 +12
Lines 837 1400 +563
======================================
+ Hits 837 1400 +563
Continue to review full report at Codecov.
|
eternal-flame-AD
force-pushed
the
plugin
branch
from
f148784
to
90e4690
Compare
|
The WebUI part is not completed yet, we can review on the go part first |
|
@eternal-flame-AD I could continue working on this PR if you want/dont have time for it. |
|
It's Chinese Spring Festival so actually I am on a vacation^_^ That's OK if you want to finish it :) |
|
Alright, didn't know that, then I'll wait till you're back (:. |
|
Thank you very much for your patience and wonderful reviewing^_^. I will come back to normal productivity shortly. |
|
Up till now, I think we have a functional API and WebUI. There are several things on the TODO list:
I think we can first review on past unresolved discussions before completing these finals |
|
Do you know why travis ci isn't building this PR? From what I see only #110 (comment) is left (while doing it, I'll surely have some remarks again as the PR is pretty big). |
|
I have no idea either:( |
There was a problem hiding this comment.
Hey, here is my attempt with my idea of the plugin manager diff on branch review/plugin. I've tried to add a implementation for the following comments #110 (comment) and #110 (comment).
With these changes only one mutex exists in the plugin.Manager, furthermore I've moved a lot stuff from the PluginAPI into the plugin.Manager.
Please share your thoughts about my attempt (:.
Nothing in the branch above is tested (still need to setup a dev environment on a linux server)
|
Okay, I would squash them now. Let's wait for a few days for the documentation to be updated and I will start to write more plugins to try out this function more deeply to spot potential underlying bugs. |
|
Should I still merge this PR or let it open, I prefer to have it closed. |
eternal-flame-AD
force-pushed
the
plugin
branch
2 times, most recently
from
e576468
to
90e3593
Compare
Fixed database migration Added a plugin system based on the go plugin package
eternal-flame-AD
force-pushed
the
plugin
branch
from
8bc1c68
to
44f905d
Compare
|
Okay I have squashed the commits. You can close this if you want to but I would recommend waiting for a few days for some new insights, since it is not ready to go to release because the documantation is not ready yet. |
|
Oke, then I'll wait. In the meantime I've create https://github.com/gotify/plugins for coordinating plugin creation. Feel free to create issues for your plugin ideas. |
|
Maybe take a look at https://github.com/eternal-flame-AD/gotify-netlify, I have set up a working building envrionment. Though I cannot get the local build environment exactly the same as what it is on travis, so I would get an error loading the plugin built on travis environment with a local built gotify server, but I think the problem will go away after the first official release with plugin is out. |
|
Hopefully this will work (:, otherwise plugins will not be very useful, or rather only useful for users with knowledge on building go programs. |
|
@eternal-flame-AD Do you by chance have experience with https://github.com/yuin/gopher-lua (or some similar scripting language go thingy) it would be great to have an alternative to go plugin system, I think the plugin code is good encapsulated so it should be fairly easy to support both (If we do this, it should be done in a separate PR). |
|
I am not very familiar with Lua but I did consider this. I would look at this later. First impression is that the Lua plugin has to be all in a single file in |
|
Okay I think this is ready. You can merge this together with the documentation PR. |
|
Yeah, will do it after some final testing which I'll probably do on the weekend. |
|
Okay, do you want me to squash the commits again or the current state is OK? |
|
The current state is ok. Could you have a look at https://github.com/gotify/build? I've added docker images for building gotify, this should unify the build environment and make it possible to locally build gotify/server and still use prebuild plugins and vice versa. I've updated https://github.com/gotify/plugin-template. |
|
Thank you for your continuous concentration on this PR:) I think building on docker is really a good idea. Okay, can you merge this into master or review/plugin so we can sort out the whole workflow? As for gotify/build I think we should not specify the command for building plugins, instead tell the builder to refer to the documentation(see my documentation PR) or the template on deploying plugins, or a builder who only read the documentation of gotify/build might build the plugin without overlaying the corresponding version of server go.mod As for the template, it will only be possible to build plugins against the master branch of server. I think we should support building against a tag, or even a commit. You can see the .travis.yml on my netlify repo for an example implementation. |
| } | ||
|
|
||
| // EnablePlugin enables a plugin. | ||
| // swagger:operation POST /plugin/:id/enable plugin enablePlugin |
There was a problem hiding this comment.
:id has to be {id}. Otherwise requests can't be made from the swagger-ui.
|
Yeah right, having a single reference how it building should be done is better. |
|
Yep. Feel free to reach to me if you want me to collaborate on the build environment or the template:) |
This fixes #51
This fixes #69
I will implement the proposal we discussed in #51 progressively. Here's a checklist:
Before merge: