🐛 fix(devcontainer): docker-compose.override.yml not picked up by JetBrains Gateway rebuilds

[codekiln]

Problem

PR #712 introduced an optional named volume configuration for JetBrains users to fix OOM crashes from gRPC FUSE file syncing. The configuration uses docker-compose.override.yml (gitignored) to allow JetBrains users to opt into a named volume while keeping Codespaces on bind mount.

However, after multiple rebuilds through JetBrains Gateway UI, the override file is not being picked up. The container still uses the bind mount from base docker-compose.yml:

$ mount | grep /workspace
grpcfuse on /workspace type fuse.grpcfuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,max_read=1048576)

Expected: langstar-workspace named volume
Actual: grpcfuse bind mount

Context

• JetBrains RustRover via Gateway
• docker-compose.override.yml correctly configured with:
  • Service-level: - langstar-workspace:/workspace
  • Top-level: langstar-workspace: volume declaration
• File is present at /workspace/.devcontainer/docker-compose.override.yml
• Rebuilt container multiple times through Gateway UI
• Issue persists despite correct configuration

Investigation

According to Docker Compose docs, docker-compose.override.yml should be automatically discovered and merged. However, when invoked through devcontainer.json with:

"dockerComposeFile": "docker-compose.yml"

It appears to only use the explicitly listed file, not the automatic override file discovery.

Initial Analysis

A deep research report at logseq-encode-garden/pages/DevContainer___Report___25___12___Multi-Env DevContainer Setup.md at main · codekiln/logseq-encode-garden found that using separate devcontainer directories has many precedents, and this is likely to be the most scalable solution.

If the devcontainer.json file needs to be kept partly in sync across VS Code, Codespaces and JetBrains, but customized for a local purpose (for example, to give another docker-compose or different bind mount configuration), a json templating language could be used, such as Jsonnet, Cue or Dhall.

Next Actions

TBD

Related

• Issue Use named volume for /workspace in devcontainer to fix JetBrains file watching #711: Original OOM crash report
• PR 🔧 build(devcontainer): use named volume for workspace to fix JetBrains file watching #712: Implemented optional named volume (worked through 3 iterations)
• Milestone: Performance/stability for JetBrains users

[codekiln]

Implementation Complete

PR incoming with three-environment devcontainer setup:

New Directory Structure

.devcontainer/
├── devcontainer.json              # VS Code local (default)
├── docker-compose.yml             # VS Code compose (bind mount, .env)
├── Dockerfile                     # Shared (added JetBrains X11 deps)
├── codespaces/                    # NEW: GitHub Codespaces config
│   ├── devcontainer.json
│   └── docker-compose.yml         # No .env dependency
└── jetbrains/                     # NEW: JetBrains Gateway config
    ├── devcontainer.json
    └── docker-compose.yml         # Hybrid mount (named vol + .devcontainer bind)

Three Environment Comparison

Config	Location	Workspace	Secrets	File Watching
VS Code Local	Default .devcontainer/	Bind mount	.env file	gRPC FUSE
Codespaces	.devcontainer/codespaces/	Cloud-managed	GitHub secrets	Cloud-managed
JetBrains	.devcontainer/jetbrains/	Named volume + .devcontainer bind	.env via bind	Native inotify

Key Changes

1. Codespaces config: Dedicated compose with NO .env dependency (uses Codespaces secrets directly)
2. JetBrains config: Hybrid mount approach - named volume for workspace + bind mount for .devcontainer (provides .env access)
3. Dockerfile: Added X11 libraries required by JetBrains Gateway (libxext6, libxrender1, libxtst6, libxi6, libfreetype6)
4. Documentation: Updated README with three-config architecture
5. Override template: Marked JetBrains override approach as deprecated, pointing to dedicated config

Testing Checklist

• VS Code local: Default config still works
• Codespaces: New config works with GitHub secrets
• JetBrains Gateway: Clone Repository workflow with hybrid mount

[codekiln]

Update: see here in PR for update;

I think there's a conceptual difference between how we need to configure vcs clone method in jetbrains and how it works in VS Code because the .env file will just not be there before it's cloned. It's more like codepsaces, but without the ability to define the environment variables ahead of time.

As a result, I think that we may need to rethink how devcontainers work with JetBrains RustRover. Unfortunately, unless there is some method of supplying secrets or environment variables to the devcontainer before creation in JetBrains RustRover, we will need to create the devcontainer in such a way that the dockerfile and post create script assumes that we do not yet have access to all the environment variables / secrets. Then, the dev will need to create a secrets file.

It's possible that the Dev Container CLI | RustRover Documentation may provide some facility to provide environment variables / secrets context to the devcontainer. But for simplicity's sake, it may be beneficial to think of the devcontainers in each environment as a two-step process: 1.) creating the base environment, 2.) having the developer create the parts of the environment that need to be initialized with secrets.

It's possible that 2 can be executed automatically in certain environments (VS Code / Cursor / Codespaces), but in RustRover, for now, it's likely that it needs to be manual.