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 curtidas

Olá,

Nenhuma conta de administrador criada

Ao usar o contêiner Docker de fora por meio dos scripts em d/ (por exemplo, d/boot_dev --init, conforme especificado em Install Discourse for development using Docker), ele me pede para configurar uma conta de administrador como parte do processo.

No entanto, ao usá-lo como um Dev Container e executar as etapas de compilação (Ctrl/Cmd + Shift + B), ele NÃO cria um administrador.

Após uma rápida olhada nas instruções, tive a impressão inicial de que criar um administrador é bastante árduo; mas depois percebi que tudo o que é necessário é este comando, deixando-o aqui para aqueles que encontrarem o mesmo problema:

rake admin:create

(ou, se reclamar sobre uma versão diferente do rake necessária: bundle exec rake admin:create)

6 curtidas

No Windows 11, se você não quiser ter problemas com finais de linha, como:

[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

.. certifique-se de \u003ckbd\u003eClonar em Volume\u003c/kbd\u003e

5 curtidas

Talvez haja uma maneira melhor, mas para trabalhar em plugins, tenho uma pasta irmã discourse-plugins ao lado da minha pasta principal do repositório discourse. Isso é montado em /workspace/plugins para que eu possa criar links simbólicos dentro do contêiner.

É isso que adicionei a mounts em devcontainer.json:
"source=${localWorkspaceFolder}/../${localWorkspaceFolderBasename}-plugins,target=/workspace/plugins,type=bind"

2 curtidas

Isso é realmente útil, obrigado.

1 curtida

… Ou apenas git reset --hard
Funcionou para mim
Em seguida, Dev Container: Rebuild Container e Ctrl-Shift-B

Se você estiver usando o OrbStack (não afiliado) em seu ambiente macOS local e quiser executar o Discourse em HTTPS com um domínio personalizado, atualize seu devcontainer.json com as seguintes adições:

  1. Dê um nome ao contêiner.
  2. Adicione o domínio curinga .orb.local à variável de ambiente RAILS_DEVELOPMENT_HOSTS (os nomes de host devem ser separados por vírgula).
--- 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", // Passo 2
     "PGUSER": "discourse",
     "SELENIUM_FORWARD_DEVTOOLS_TO_PORT": "9229",
   },
+  "runArgs": ["--name","discourse"], // Passo 1
   "mounts": [
     "source=${localWorkspaceFolderBasename}-node_modules,target=${containerWorkspaceFolder}/node_modules,type=volume",
     "source=${localWorkspaceFolderBasename}-pg,target=/shared/postgres_data,type=volume",

p.s. por favor, me avise se você souber como definir o nome de host *.orb.local e o nome do contêiner dinamicamente, como é definido para o GitHub Codespaces. Definir o valor como .app.github.dev,.orb.local não funcionou para mim.

Atualização: De alguma forma, estava faltando um registro no meu arquivo /etc/hosts. Após adicionar esta linha, pude usar o domínio curinga .orb.local no passo 2.

Com essas alterações no arquivo devcontainer.json, agora posso executar minha instância local do Discourse em \u003chttps://discourse.orb.local/\u003e

/etc/hosts

Adicione esta linha ao seu arquivo /etc/hosts se você ainda não o tiver.

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

Dica bônus 1
Se, por algum motivo, suas configurações de rede, ou a rede VPN da sua empresa, etc., entrarem em conflito com os intervalos de IP de contêiner do OrbStack, atualize seu OrbStack com um intervalo diferente.

Dica bônus 2
Se você omitir o passo 1, o OrbStack criará um contêiner com um nome aleatório, mas você ainda poderá usar HTTPS sem adicionar nenhum número de porta. A desvantagem é o nome do contêiner, portanto, o nome do domínio será atualizado toda vez que você reconstruir o contêiner.