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.
I noticed the hardcoded stuff too, yet there are references to a port config in yml files as well as ENV variables. I’m giving up on this for now. Way too much time invested already for what I wanted to test.
@merefield quick question: is there a faster way to get plugin code updates in the container than doing d/shutdown_dev; d/boot_dev which takes ages and download a crap ton of data as it pulls docker images? Doing that every time I change a line of code to test in the browser seems utterly overkill even for a dockerized env
Restarting the rails server with d/rails s doesn’t see my plugin’s code changes.