Developing Discourse using a Dev Container

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 FileOpen 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 « J'aime »

Salut,

Aucun compte administrateur créé

Lorsque j’utilise le conteneur Docker de l’extérieur via les scripts dans d/ (par exemple, d/boot_dev --init comme spécifié dans Install Discourse for development using Docker, il me demande de créer un compte administrateur dans le cadre du processus.

Cependant, lorsque je l’utilise comme conteneur de développement et que j’exécute les étapes de construction (Ctrl/Cmd + Maj + B), il ne crée PAS d’administrateur.

En parcourant rapidement les instructions, j’ai d’abord eu l’impression que la création d’un administrateur était assez ardue ; mais j’ai ensuite réalisé qu’il suffisait de cette commande, je la laisse ici pour ceux qui rencontrent le même problème :

rake admin:create

(ou, s’il se plaint d’une version de rake différente requise : bundle exec rake admin:create)

6 « J'aime »

Sur Windows 11, si vous ne voulez pas rencontrer de problèmes de fin de ligne, tels que :

[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

.. assurez-vous de Cloner dans le volume

5 « J'aime »

Peut-être existe-t-il une meilleure façon, mais pour travailler sur les plugins, j’ai un dossier frère discourse-plugins à côté de mon dossier principal de dépôt discourse. Cela se monte sur /workspace/plugins afin que je puisse ensuite créer des liens symboliques dans le conteneur.

Voici ce que j’ai ajouté à mounts dans devcontainer.json :
"source=${localWorkspaceFolder}/../${localWorkspaceFolderBasename}-plugins,target=/workspace/plugins,type=bind"

2 « J'aime »

C’est très utile, merci.

1 « J'aime »

… Ou juste git reset --hard
Ça a marché pour moi
Ensuite Dev Container: Rebuild Container et Ctrl-Shift-B

Si vous utilisez OrbStack (non affilié) sur votre environnement macOS local et que vous souhaitez exécuter Discourse sur HTTPS avec un domaine personnalisé, mettez à jour votre devcontainer.json avec les ajouts suivants :

  1. Donnez un nom au conteneur.
  2. Ajoutez le domaine générique .orb.local à la variable d’environnement RAILS_DEVELOPMENT_HOSTS (les noms d’hôte doivent être séparés par une virgule).
--- 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", // Étape 2
     "PGUSER": "discourse",
     "SELENIUM_FORWARD_DEVTOOLS_TO_PORT": "9229",
   },
+  "runArgs": ["--name","discourse"], // Étape 1
   "mounts": [
     "source=${localWorkspaceFolderBasename}-node_modules,target=${containerWorkspaceFolder}/node_modules,type=volume",
     "source=${localWorkspaceFolderBasename}-pg,target=/shared/postgres_data,type=volume",

p.s. faites-moi savoir si vous savez comment définir dynamiquement le nom d’hôte *.orb.local et le nom du conteneur, comme c’est défini pour GitHub Codespaces. Définir la valeur comme .app.github.dev,.orb.local n’a pas fonctionné pour moi.

Mise à jour : D’une manière ou d’une autre, il me manquait une entrée dans mon fichier /etc/hosts. Après avoir ajouté cette ligne, j’ai pu utiliser le domaine générique .orb.local à l’étape 2.

Avec ces modifications dans le fichier devcontainer.json, je peux maintenant exécuter mon instance Discourse locale à l’adresse \u003chttps://discourse.orb.local/\u003e

/etc/hosts

Ajoutez cette ligne à votre fichier /etc/hosts si elle n’y figure pas déjà.

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

Astuce bonus 1
Si, pour une raison quelconque, vos paramètres réseau, votre réseau VPN d’entreprise, etc. entrent en conflit avec les plages d’adresses IP des conteneurs d’OrbStack, mettez à jour votre OrbStack avec une plage différente.

Astuce bonus 2
Si vous omettez l’étape 1, OrbStack créera un conteneur au nom aléatoire, mais vous pourrez toujours utiliser HTTPS sans ajouter de numéro de port. L’inconvénient est le nom du conteneur, donc le nom de domaine sera actualisé à chaque reconstruction du conteneur.