Problems with understanding the development of Discourse
Mikhail_Tyuftyaev is having trouble understanding the differences between their local Discourse installation and a virtual machine installation using Docker. They are also unsure about synchronizing the two installations using Git and what would happen if Docker is stopped on the virtual machine.
rudzainy provides a video link to help explain Docker and suggests that running Docker locally is useful for testing compiled code before deploying to a production server.
merefield explains that the presence or absence of Docker is irrelevant for most plugin and theme component development. They advise against obsessing over exact versions or configurations and instead recommend following good practices to make add-ons more robust to changes within Discourse core.
Mikhail_Tyuftyaev thanks merefield for their answer and asks if they can delete a Docker-related line from their app.yaml file. merefield advises against changing the default scripts used to maintain Docker dev unless there is a good reason to do so, and suggests asking further questions on a Docker dev topic.
according to this guide. Here I develop a discourse, themes and plugins.
I also have a discourse installed on a virtual machine using docker according to this guide
These installations work wonderfully.
I don’t understand what docker is and why the files on the virtual machine are different from the files on the local computer.
What will happen if you stop docker on a virtual machine using the command d/shutdown_dev ?
How can I synchronize these two installations using Git?
Can I install docker on a local machine and for what?
The presence or not of docker is kind of irrelevant for almost all plugin and theme component development. This is a separate concern. I don’t run a docker instance in dev.
When developing addons for Discourse you shouldn’t need to obsess over the exact version or configuration of your dev instance versus production because you normally have no control over most of the instances your plugin will end up on in any case if it is open source. The most important thing is to follow good practice to make your add-on more robust to changes within Discourse core. Even if you are only developing for your own discourse instance you still have no control over discourse core changes so same approach applies.
Slightly different versions should NOT generally cause your plugin or theme component to fail. It can but it’s not consistent. My plug-ins and TCs can go months without needing changes so work on core commits months apart
I normally update my dev instance to latest master when working on plugin changes (fixes or enhancements) so I can sweep up any breaking changes. This is simply achieved by a git pull, bundle install and db:migrate.
Production instances should just be updated via the front end or the command line rebuild.
My advice would be to get a plugin out there in public and attract users and learn the bumps of the road with experience. Don’t procrastinate too much: do! And don’t worry about making mistakes because they help you learn.
I would ask such questions on the docker dev Topic. For now I would not change the out of the box scripts used to maintain docker dev unless you have very good reason, presumably they are there to help you.
