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.

12 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 the matching hostname to RAILS_DEVELOPMENT_HOSTS environment variable.
--- 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,discourse.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.