I had a few random ideas that popped into my head, and one of them was a plugin to install plugins. That requires a forum rebuild. Is there a way to rebuild using Ruby? I really don’t want to try:
p `cd ../../`
p `. /launcher rebuild app`
I had a few random ideas that popped into my head, and one of them was a plugin to install plugins. That requires a forum rebuild. Is there a way to rebuild using Ruby? I really don’t want to try:
p `cd ../../`
p `. /launcher rebuild app`
In a standard install, Discourse (and therefore, plugins) are running inside a docker container. That container does not have complete access to the host filesystem, so it can’t access the host’s /var/discourse
directory to modify app.yml
or run launcher
.
And even if it could… there’s a bit of a circular dependency here. Running ./launcher rebuild
would kill the docker container… which would kill the launcher rebuild
which you started from the plugin
There are potential solutions here. e.g. adding additional docker volume mounts, so that the config/launcher can be accessed from within the container. But it’s not trivial.
IIRC someone once made a ‘plugin manager’ plugin… which required some tweaks to the app.yml to add things like the volume mount. But I can’t find any topics about it now, so I assume it’s no longer maintained. Perhaps someone else can share a link if they can find it? (or maybe it was all a dream )
On the CDCK side, we definitely err towards using themes when we want customers to be able to install/update/uninstall at will. Allowing people to arbitrarily install plugins isn’t an option, because that would affect other customers running on the same server.
Yep, here it is:
Hmm… I see.
Oh, whoops, I didn’t think of that!
Dashboard.literatecomputing.com will install and remove plugins by editing the app.yml (or web_only.yml) and doing the rebuild (actually, bootstrap, destroy, rebuild). On a two container install, the downtime is minimal.
It also does stuff like upgrade docker, and postgres, docker prune, and so on. Since it’s all managing a standard install, you’re not tied in to it, and it can’t break anything unless it’s actually doing something (like installing a bad plugin).
It’s a (private) discourse plugin that drives an ansible playbook. You can join the free trial group and use it for free (with limited support).
This plugin seems to just clone the repository into the /plugins
directory. Interesting.
ProCourse Installer was amazing! It’s too bad it created issues for some plugins.
You can do something like this inside the container to add a plugin to an existing container:
cd /var/www/discourse/plugins
git clone my-plugin-url
rake db:migrate assets:precompile
sv restart unicorn
But the problems of keeping the plugins in the container and in the app.yml
for when you rebuild next are there.
I’ve been burned a number of times doing a ./launcher destroy app;./launcher start app
to apply new ENV variables from app.yml
only to find that the “new” container is behind the version that the database is. It’s even worse if someone has upgrade only some plugins in the container that worked with the version of Discourse that was in the old container, but not with the one that you get when you rebuild. . .
So that’s why the ProCouese plugin only cloned the repositories, and can only be removed via that plugin page to rm -rf
the vloned plugin folder.
It actually worked quite decently as a proof of concept. It could use some tweaks though as it was said it could make troubleshooting more difficult. So maybe need some command line info how to access the procouree installer. Maybe better log file.
The plus though is you can disable all plugins simply by removing l/commenting out pro course installer. Though it is broken now.
Joe has some very forward ideas. Iirc he made the initial Post Voting plugin?