I have a standard (edit: non-dev) docker install in /var/discourse. Is it possible to use a local plugin directory to load in Discourse instead of linking to a remote github repo from app.yml? If yes, how?
I tried two methods that I thought should be working:
Cloned discourse-math from github into /var/discourse/plugins/discourse-math. launcher rebuild said nothing about discourse-math and there is no discourse-math in the docker mount either, nor in the GUI. So I guess the plugins folder is ignored?
I also tried cloning into a different dir outside of /var/discourse and symlink-ing it to /var/discourse/plugins/discourse-math … same outcome.
Cloned the github repo in /var/discourse-math.git and edited my app.yml to say - git clone file:////var/discourse-math.git but then launcher rebuild complained fatal: '/var/discourse-math.git' does not appear to be a git repository … supposedly the launcher runs this in a docker container already? Manually running cd /tmp && git clone file:////var/discourse-math.git works just fine.
Right, yes, I was aware of the dev install, but I have a standard docker install (i.e. non-dev install), so I guess my question is still standing: can I sideload a plugin from a local directory or only remotely from github via app.yml?
p.s. I’m well aware the “correct” flow is to to have a dev install and play there. I wanted a quick and dirty way to mod and test a plugin instead of going through the entire pain of a dev install and setup
Just to make sure I got you correctly: You are referring to it cloning remote github plugins, and not able to clone from a local directory, even via github file:///? I take it that launcher.sh at that point runs in a container and not in the host, i.e. clones from github while in the container, instead of cloning from the host into the host’s mounted folder … which would allow me to git clone file:///…
If you want to turn the production install into a Frankenstein that is able to access the local mounted directories, you will need to change the build scripts to give it that access. You would need to be responsible to support those customisations yourself.
imho you are just creating work and fragility for yourself.
the docker dev install is precisely designed to give you a low maintenance solution for efficient local plugin development, please consider using it.
I’d be grateful for a tip for a way to edit a current js file in the container (as cringy as it sounds) and make it visible by the browser.
I might have already ended up in the “Didn’t have the time to write a short letter” teritorry … I didn’t have the time to go on the proper route of a dev install and I didn’t expect it to be this hard to mod a js file inside the container (little time to read up on how Discourse caches plugin js files to make my changes visible in the browser), etc etc
Not sure a Theme component helps when I need to mod a file like this … that file (along with others), as i understand, goes through the mapper etc, to produce the container’s /var/www/discourse/public/applets/plugins/discourse-math-<id>.js file that the browser loads. I only need to change the latter, but the browser still sees the old file, as if there was server-side caching.
The local dev install is time and hassle consuming but may do it if all fails. I didn’t expect a dirty mod of a plugin js to be so painful. I also still don’t understand why my direct edits aren’t visible in the browser, unless there is server-side caching in the container’s nginx (no idea why given it’s a js)
Anyway, the time i had to look into this today is up :(. Thanks for help regardless!
The dev tooling has evolved for exactly this purpose, so if you can, use it. Setup of the dev docker environment should take minutes, not hours and you should only need to do it once, then it’s useful for all sorts of purposes subsequently. Don’t be tempted to use the production install locally only because you are familiar with it! It’s simply not configured for that purpose.
Call me stupid but how do I change the default port 3000 to something else? d/boot-dev --init fails as I’m using that port for something else. I tried -e UNICORN_PORT=4200. The guides I’ve seen say nothing about the port. The thin.yml file in config/cloud/cloud66/files seems to be ignored too
Well, d/boot_dev --init fails (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). Maybe I’ll take this further later. Thanks for your time. I wish these things were better documented.