Developing Discourse using a Dev Container

Documentation Developer Guides
1

Dev Containers is an open standard for configuring a development environment inside a container. This almost entirely eliminates the need to install/configure Discourse-specific tools/dependencies on your local machine, and makes it very easy to keep up-to-date as Discourse evolves over time.

Dev Containers can be used in a number of different IDEs, or directly using their reference CLI. This guide will describe the setup process for VSCode.

Getting started

  1. Download and install VSCode

  2. Install the Dev Containers extension in VSCode

  3. Clone the Discourse repository onto your machine

    git clone https://github.com/discourse/discourse

  4. In VSCode, use File ā†’ Open Folder, then choose the Discourse directory

  5. Open the folder in its Dev Container. This can be done via the popup prompt, or by opening the command palette (Cmd/Ctrl + Shift + P) and searching for ā€œOpen folder in containerā€¦ā€

  6. If this is your first time launching a container, you will be prompted to install and start Docker Desktop. Once complete, go back to VSCode re-run ā€œOpen folder in containerā€¦ā€

  7. Wait for the container to download and start. When itā€™s done, the README will appear, and youā€™ll see the Discourse filesystem in the sidebar.

  8. Run the default build task using Ctrl + Shift + B (Cmd + Shift + B on mac).

    This will install dependencies, migrate the database, and start the server. Itā€™ll take a few minutes, especially on the lower-end machines. Youā€™ll see ā€œBuild successfulā€ in the terminal when itā€™s done.

  9. Visit http://localhost:4200 in your browser to see your new Discourse instance

  10. All done! You can now make changes to Discourseā€™s source code and see them reflected in the preview.

Applying config/container updates

Every so often, the devcontainer config and the associated container image will be updated. VSCode should prompt you to ā€œrebuildā€ to apply the changes. Alternatively, you can run ā€œDev Containers: Rebuild Containerā€ from the VSCode command palette. The working directory, and your Redis/Postgres data will be preserved across rebuilds.

If youā€™d like to start from scratch with fresh database, youā€™ll need to delete the discourse-pg and discourse-redis docker volumes. This can be done from the ā€œRemote Explorerā€ tab of the VSCode sidebar.

Discourseā€™s sample vscode .vscode/settings.json and .vscode/tasks.json will be copied when you first boot the codespace. From that point forward, if you want to use the latest sample config, youā€™ll need to manually copy .vscode/settings.json.sample to .vscode/settings.json.

References

This document is version controlled - suggest changes on github.

13 Likes
2

Hi,

No admin account created

When using the docker container from outside via the scripts in d/ (e.g. d/boot_dev --init as specified in Install Discourse for development using Docker , it asks me to set up an admin account as part of the process.

However, when using it as a Dev Container and running the build steps (ctrl/cmd + shift + b) it does NOT create an admin.

From glancing at the instructions, I first had the impression that creating an admin is quite arduous; but then I realized that all it takes is this command, leaving it here for those who run into the same issue:

rake admin:create

(or, if it complains about a different rake version required: bundle exec rake admin:create)

5 Likes
3

On Windows 11, if you donā€™t want to run into line ending issues, such as:

[23963 ms] Start: Run in container: /bin/sh -c ./.devcontainer/scripts/start.rb
/usr/bin/env: ā€˜ruby\rā€™: No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines

ā€¦ make sure to Clone in Volume

Code_IKydlULXhL
Code_IKydlULXhL551Ɨ157 8.46 KB

5 Likes
4

Maybe there is a better way, but to work on plugins I have a discourse-plugins sibling folder alongside my main discourse repo folder. This mounts to /workspace/plugins so I can then create symlinks within the container.

This is what I added to mounts in devcontainer.json:
"source=${localWorkspaceFolder}/../${localWorkspaceFolderBasename}-plugins,target=/workspace/plugins,type=bind"

1 Like
5

čæ™ē”®å®žęœ‰ē”Øļ¼Œę„Ÿč°¢ć€‚

1 Like
6

ā€¦ Or just git reset --hard
Worked for me
Then Dev Container: Rebuild Container and Ctrl-Shift-B

7

If you are using OrbStack (not affiliated) on your local macOS environment, and want to run Discourse on HTTPS with a custom domain, update your devcontainer.json with following additions:

  1. Give a name to the container.
  2. Add .orb.local wildcard domain to RAILS_DEVELOPMENT_HOSTS environment variable (hostnames must be separated by a comma).
--- a/.devcontainer/devcontainer.json
+++ b/.devcontainer/devcontainer.json
@@ -13,10 +13,11 @@
   ],
   "remoteUser": "discourse",
   "remoteEnv": {
-    "RAILS_DEVELOPMENT_HOSTS": ".app.github.dev",
+    "RAILS_DEVELOPMENT_HOSTS": ".app.github.dev,.orb.local", // Step 2
     "PGUSER": "discourse",
     "SELENIUM_FORWARD_DEVTOOLS_TO_PORT": "9229",
   },
+  "runArgs": ["--name","discourse"], // Step 1
   "mounts": [
     "source=${localWorkspaceFolderBasename}-node_modules,target=${containerWorkspaceFolder}/node_modules,type=volume",
     "source=${localWorkspaceFolderBasename}-pg,target=/shared/postgres_data,type=volume",

p.s. please let me know, if you know how I can set the *.orb.local hostname and the container name dynamically, as it is defined for GitHub Codespaces. Setting the value as .app.github.dev,.orb.local didnā€™t work for me.

Update: Somehow, I was missing a record in my /etc/hosts file. After adding this line, I was able to use .orb.local wildcard domain in step 2.

With these changes in the devcontainer.json file, now I can run my local Discourse instance at https://discourse.orb.local/

/etc/hosts

Add this line to your /etc/hosts file if you donā€™t already have it.

##
# Docker and OrbStack
##
127.0.0.1 host.docker.internal

Bonus tip 1
If somehow your network settings, or your company VPN network, etc conflicts with OrbStackā€™s Container IP ranges, update your OrbStack with a different range.

Bonus tip 2
If you omit the step 1, OrbStack will create a randomly named container, but you will still be able use HTTPS without appending any port number. Downside is the container name, thus the domain name will be refreshed every time you rebuild the container.