mirror of
https://github.com/zed-industries/zed.git
synced 2026-05-26 15:44:20 +00:00
dc3f5b9972
## Before you mark this PR as ready for review, make sure that you have: - [x] Added a solid test coverage and/or screenshots from doing manual testing - [x] Done a self-review taking into account security and performance aspects - [x] Aligned any UI changes with the [UI checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) ## Summary Adds a `--dev-container` CLI flag that automatically triggers "Reopen in Dev Container" when a `.devcontainer/` configuration is found in the project directory. ```sh zed --dev-container /path/to/project ``` ## Motivation This enables fully scripted dev container workflows — for example, creating a git worktree and immediately opening it in a dev container without any manual UI interaction: ```sh git worktree add ../feature-branch zed --dev-container ../feature-branch ``` The dev container modal fires automatically once the workspace finishes initializing, so the environment is ready by the time you look at the window. This is useful for automation scripts that prepare environments and kick off agent runs for tasks like bug report triage. Here's an [example script](https://github.com/antont/todo-rs-ts/blob/main/scripts/devcontainer-new.sh) that creates a worktree and opens it as a dev container in one step. Related: #48682 requests a `devcontainer://` protocol for connecting to already-running dev containers — a complementary but different use case. This PR covers the "open project and trigger dev container setup" path. ## How it works - The `--dev-container` flag flows through the CLI IPC protocol to the workspace as an `open_in_dev_container` option. - On the first worktree scan completion, if devcontainer configs are detected, the dev container modal opens automatically. - If no `.devcontainer/` config is found, the flag is cleared and a warning is logged. ## Notable changes - **`Workspace::worktree_scans_complete`** promoted from `#[cfg(test)]` to production. It was only test-gated because it had no production callers — it's a pure read-only future with no side effects. - **`suggest_on_worktree_updated`** now takes `&mut Workspace` to read and clear the CLI flag. - Extracted **`open_dev_container_modal`** helper shared between the CLI code path and the suggest notification. ## Test plan - [x] `cargo test -p zed open_listener` — includes `test_dev_container_flag_opens_modal` and `test_dev_container_flag_cleared_without_config` - [x] `cargo test -p recent_projects` — existing suggest tests still pass - [x] Manual: `cargo run -- --dev-container /path/to/project-with-devcontainer` opens the modal Release Notes: - Added `--dev-container` CLI flag to automatically open a project in a dev container when `.devcontainer/` configuration is present. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| build.rs | ||
| Cargo.toml | ||
| LICENSE-GPL | ||
| README.md | ||
Cli
Testing
You can test your changes to the cli crate by first building the main zed binary:
cargo build -p zed
And then building and running the cli crate with the following parameters:
cargo run -p cli -- --zed ./target/debug/zed.exe