Problems with understanding the development of Discourse

dev
1

Hello everyone.
I have a discourse installed on my local computer on

http://localhost:4200/

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?

Please help me understand these questions

2

Let me try to illustrate the flow:

  1. Work on your codebase (inside /discourse).
  2. Compile your codebase into a Docker Container.
  3. Deploy that Docker Container to your production server.

One use case for running Docker locally is to test your newly compiled Docker Container before you deploy to your production server.

1 Like
3

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.

6 Likes
4

Thank you very much for your answer.
I will try to develop
That is, I can delete “git clone /github…docker” from the app.yaml file?
And rebuild it?

5

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.

1 Like
6

I understand you. Thanks

1 Like