Haha, as I said, I’m using it for something else, I can’t just kill it. Surely it shouldn’t be that hard to change the port (famous last words it seems)
1 Like
Suggest you ask that on the linked topic, from my brief look at that script it looks hard coded, but could be wrong, the script might be built.
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.
Spun up a VM with a fresh Ubuntu 22.04. The dev install craps out: Beginners Guide to Install Discourse for Development using Docker - #213 by nordize
Not my day … but definitely not minutes either (no pun intended). Thanks for your time, and sorry you had to waste it too.
1 Like
@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.
This should only be necessary if you remove or add a plugin, not if you change a line of code.
If that line is Ruby or CSS it will hot load the new code. If Ruby you should see the unicorns restarting in the terminal iirc.
If it is javascript you just have to refresh the browser.
I should have mentioned my plugin is in a symlink, and any changes are not reflected unless you do d/shutdown_dev; d/boot_dev (this is also mentioned in the guide), but I was hoping there is a workaround via docker itself since these should be just mapped filed. I might ask in the other thread or see if I can mod it as a workaround (or not use symlinks).
This doesn’t sound right to me. The server process simply restart just as it does in a non-docker install. Symlinks should make no difference and is the appropriate way to work. I have no idea why yours is not behaving this way …
Well, feel free to try it. I wouldn’t have posted if restarting rails and ember was enough. As I was saying, the guide also points this out.
As per the guide, running those restart commands should only be necessary if you change the population of plugins (e.g. by removing or adding a valid symlink). Otherwise, Rails should detect code changes and restart its processes. It might be possible to turn off this behaviour in configuration, but that should be the default.
Here’s an example of the automated restart, albeit on a non-docker dev install, but the behaviour should be similar:
[DEV]: Edited files which are not autoloaded. Restarting server...
- plugins/discourse-multilingual/extensions/post.rb
RESTARTING UNICORN
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : reaped #<Process::Status: pid 228047 exit 0> worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : reaped #<Process::Status: pid 228048 exit 0> worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : reaped #<Process::Status: pid 228049 exit 0> worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : master complete
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : Refreshing Gem list
Got TERM signal
Shutting down
Terminating quiet threads
Scheduler exiting...
Pausing to allow jobs to finish...
Bye!
Starting CSS change watcher
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : listening on addr=0.0.0.0:3000 fd=25
I edited the file post.rb and hit save, the rest is automated.
Sorry I don’t have access to my docker based dev machine where I am at present to confirm this is the case on the docker install too, but recall that it is, unless something changed.
I’m not making it up, you know 
and I can’t do much with being told it should work I followed that guide to the letter on a new VM install with Ubuntu 22.04.
- Symlinking the plugin into the discourse/plugins/ subfolder and changing JS code in the plugin is not seen unless I do d/shutdown_dev; d/boot_dev, despite restarting d/rails s and d/ember-cli
- Copying the plugin into the discourse/plugins/ subfolder and changing JS code in the plugin is seen without doing d/shutdown_dev; d/boot_dev but only restarting d/rails s and d/ember-cli
Feel free to try the above. The plugin in question is discourse-math, changing code in assets/initializers/javascript/*.js (keep in mind that these particular plugin files are side-loaded, and not GET called by the browser directly; not sure if that makes a difference, I haven’t dug too deep yet into how Discourse works internally).
p.s. I know I need to refresh the browser (bypassing cache) … give me some credit.
From the horses mouth as it were:
So the issue is possibly local to you, or some regression in the current build, but the latter seems unlikely.
I give up, you win. If you ever try it yourself then let me know.
I’m certainly not trying “to win”, but we must get to a baseline of understanding:
- it’s supposed to auto-restart on back-end code changes.
-
d/shutdown_dev; d/boot_devshould only be necessary when you change the population of plugins not just individual lines of code.
This should reduce where you need to look to fix things.
I just git pulled and tried a change, it restarts, so it’s not a build regression.
The even weirder part for me is that being a docker setup, it’s actually harder to inadvertently override the packaged behaviour, so it should be more reliable.
I will try this out on my docker build when I get home.
Appreciate this is frustrating and annoying as a workflow at present, it would certainly annoy and frustrate me.
If you’ve fully cleared your cache I’m not sure what to suggest at this stage.
Note that initializers only run once when you open the page for the first time. So the server processes restarting is moot (and only covers the back-end code).
I’m running dev tools with cache disabled whenever I develop web apps. I’m only new to Discourse code and tooling, not to (web) development. I posted a question in the guide thread as well. For now I just copied the plugin dir under discourse/plugins/ to avoid the pain
1 Like
I will try something similar later today and report back.
As far as I can see from the browser calls, the JS code from the initializer JS is side-loaded through discourse-math.js, via eval() (on every page open), which clearly suggests that some server side component is processing and caching that JS code from the initializer (which is the one I’m changing), and hence it’s that particular server-side cacher that needs to be triggered into re-caching it … which doesn’t happen if the plugin is symlinked but does when it’s copied.
I’m not familiar (and I didn’t want to get familiar at this time due to lack of time) with the Discourse toolchain … hence my reverse-engineering and questions.
1 Like
non-docker dev:
I tried this just now on an initializer, no restart of any process necessary, just refresh of the browser picked up the change in the js code … this was non-docker … I’ll try that later
some time later…
docker-dev:
OK now got to my PC and tried the docker solution for which I did a completely fresh install, and I’m seeing the same behaviour: edits to the initialiser working for me leaving the servers running and simply saving the file and refreshing the browser, no rebuild of the container is necessary.
So same behaviour
(I used the Discourse Locations plugin as the example.)
Are you sure nothing is wrong with your initializer?
Given it works after restart, yes, I’m sure. For 100% reliable reproducibility, you could try the specific plugin I mentioned, enabling it in the GUI and choosing the Katex option in the GUI, then editing the initializer JS file I mentioned, then making a post with Latex code inside; this plugin may be special, possibly loading its JS initializer on the fly only if the post contains Latex code (that’s what I would do if I designed Discourse) … but I don’t expect you to waste time on this issue, nor am I trying to persuade you that I’m not making things up
1 Like
Yes good point.
That is very very strange.
My only suggestion for time being is to switch to non-docker install (which takes longer to set up unfortunately 
) and see how that goes?
It would be good to get some input from team as to what might be going wrong for you. However the docker solution would surely reduce the chances of different behaviour here as is it containerised and atomic 