Add experimental Dev Container support to Positron #10884
Conversation
|
E2E Tests 🚀 |
There was a problem hiding this comment.
Pull request overview
This PR adds experimental Dev Container support to Positron, implementing a subset of the VS Code Dev Containers functionality. The implementation uses a lightly modified version of the MIT-licensed Dev Containers CLI reference implementation to derive container management commands that are executed in Positron terminals for visibility. The feature is behind an experimental flag and focuses on the most common workflows: building/rebuilding containers and opening workspaces inside containers. Several advanced features are not yet implemented, including musl-based Linux support, docker compose, container management features, and volume support.
Reviewed changes
Copilot reviewed 69 out of 113 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
extensions/positron-dev-containers/src/spec/spec-node/devContainers.ts |
Core provisioning logic for dev containers including Docker parameter creation and logging setup |
extensions/positron-dev-containers/src/spec/spec-node/containerFeatures.ts |
Implementation for extending container images with dev container features, including BuildKit support and feature layer generation |
extensions/positron-dev-containers/src/spec/spec-node/configContainer.ts |
Configuration resolution logic for dev containers, handling different config types (image, dockerfile, compose) |
extensions/positron-dev-containers/src/spec/spec-node/commandGeneration.ts |
Command generation utilities for creating docker commands without executing them |
extensions/positron-dev-containers/src/spec/spec-node/collectionCommonUtils/*.ts |
Package, publish, and docs generation utilities for dev container features and templates |
extensions/positron-dev-containers/src/spec/spec-configuration/*.ts |
Configuration parsing, OCI registry handling, and feature/template management |
extensions/positron-dev-containers/src/spec/spec-common/*.ts |
Common utilities including variable substitution, shell server, git operations, and process management |
extensions/positron-dev-containers/extension.webpack.config.js |
Webpack configuration for the extension |
build/npm/dirs.js |
Added extension directory to npm build configuration |
Files not reviewed (1)
- extensions/positron-dev-containers/package-lock.json: Language not supported
Comments suppressed due to low confidence (1)
extensions/positron-dev-containers/src/spec/spec-common/commonUtils.ts:1
- Missing indentation on line 1123. The
awaitstatement should be indented to align with the content of theifblock.
/*---------------------------------------------------------------------------------------------
extensions/positron-dev-containers/src/spec/spec-node/containerFeatures.ts
Show resolved
Hide resolved
extensions/positron-dev-containers/src/spec/spec-configuration/containerCollectionsOCI.ts
Show resolved
Hide resolved
extensions/positron-dev-containers/src/spec/spec-configuration/lockfile.ts
Show resolved
Hide resolved
extensions/positron-dev-containers/src/spec/spec-configuration/httpOCIRegistry.ts
Show resolved
Hide resolved
austin3dickey
left a comment
austin3dickey
left a comment
There was a problem hiding this comment.
some really early comments - I haven't looked at the code yet, or even got it to work all the way, since I need to set up the "get a dev build into the container" thing still. But WIP!
|
|
||
| ## Requirements | ||
|
|
||
| - Docker or Podman installed and running |
There was a problem hiding this comment.
I'm gonna use OrbStack, wish me luck
There was a problem hiding this comment.
it worked! (it's basically the same as docker haha)
| "command": "remote-containers.settings", | ||
| "title": "%command.settings%", | ||
| "category": "%command.category%" | ||
| }, |
There was a problem hiding this comment.
nit: I'm seeing some of these commands when the feature flag is off, and they don't work. (Not a big deal)
There was a problem hiding this comment.
You're right, we should just hide these. Done in cb2ae26
| const mounts: string[] = []; | ||
| if (devContainerConfig.mounts) { | ||
| for (const mount of devContainerConfig.mounts) { | ||
| mounts.push(mount); |
There was a problem hiding this comment.
I tried to build the Positron devcontainer and it didn't work because the docker create command had --mount [object Object]. If we don't want to support these complex mounts right now can we throw a more informative error?
| const generateShellScript = () => { | ||
| let script = '#!/bin/sh\nset -e\n\n'; | ||
| script += '# Trap errors to keep terminal open so user can see what failed\n'; | ||
| script += 'trap \'echo ""; echo "==> ERROR: Build failed! Press Enter to close this terminal..."; read dummy\' ERR\n\n'; |
There was a problem hiding this comment.
When I press enter to close the terminal, it pops up a toast. Can we suppress this?
This change adds early, experimental support for Dev Containers to Positron.
Because the feature is experimental, it is currently behind a feature flag:
The goal of this change is to enable the most common dev container workflows that center around building (or rebuilding) a container and opening the workspace inside the container. However, note that in this early version, many features are not implemented or are incomplete. Specifically:
musl(non-glibc) remote hosts & backends #10468); the container must be running a version of Linux already supported by Positrondocker compose)devcontainer.jsonfiles/workspaces/foo)For compatibility, the new extension uses largely the same command names and settings as the official VS Code Dev Containers extension.
It also includes a lightly modified version of the Dev Containers CLI reference implementation. The implementation is used to derive the correct container management commands, which are (generally) executed in Positron terminals for visibility.
Addresses #4691.
Release Notes
New Features
Bug Fixes
QA Notes
Like Remote SSH, this feature is difficult to test outside release builds since it needs to download a matching server component into the container. And -- also like remote SSH -- there's a setting to change the download URL. If you need to test a build that doesn't have a released Positron version to download, you can change this setting to the URL of the closest matching build.
This feature should be tested across all three operating systems since the Docker integration is somewhat OS-specific.