fix: derive workspace from devcontainer config when using -c flag#185
fix: derive workspace from devcontainer config when using -c flag#185lohrm-stabl wants to merge 1 commit intomainfrom
Conversation
When specifying a custom devcontainer path with the -c flag, the workspace path is now automatically derived from the devcontainer config location instead of requiring the path to exist on the host filesystem. This fix addresses the issue where users couldn't open projects with custom devcontainer configurations because the workspace path validation was checking for container paths on the host filesystem. Changes: - Modified main.rs to derive workspace root from devcontainer config when -c flag is provided - Added support for container path parsing (e.g., /workspace/vscli/tests) to extract subfolder information - Updated launch.rs to accept subfolder parameter - Modified workspace.rs open() method to append subfolder to container workspace path The fix now properly handles: - Devcontainer configs in .devcontainer/ folders - Container paths like /workspace/<name>/<subfolder> - Relative subfolder paths - Absolute host paths relative to workspace root Fixes #82
There was a problem hiding this comment.
3 issues found across 3 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/workspace.rs">
<violation number="1" location="src/workspace.rs:207">
P2: Normalize subfolder separators before appending to `container_folder`; Windows `\` separators can produce invalid `vscode-remote` URI paths.</violation>
</file>
<file name="src/main.rs">
<violation number="1" location="src/main.rs:69">
P1: Workspace root derivation is incorrect for nested `.devcontainer/**/devcontainer.json` paths; it picks the config directory instead of the project root.</violation>
<violation number="2" location="src/main.rs:85">
P1: Container paths are parsed as valid input, but the flow still canonicalizes the original `/workspace/...` host path when persisting history, causing a runtime error.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| .ok_or_else(|| color_eyre::eyre::eyre!("Invalid config path"))?; | ||
|
|
||
| // If config is in .devcontainer folder, use its parent as workspace | ||
| let workspace_root = if config_parent |
There was a problem hiding this comment.
P1: Workspace root derivation is incorrect for nested .devcontainer/**/devcontainer.json paths; it picks the config directory instead of the project root.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/main.rs, line 69:
<comment>Workspace root derivation is incorrect for nested `.devcontainer/**/devcontainer.json` paths; it picks the config directory instead of the project root.</comment>
<file context>
@@ -58,8 +58,56 @@ fn main() -> Result<()> {
+ .ok_or_else(|| color_eyre::eyre::eyre!("Invalid config path"))?;
+
+ // If config is in .devcontainer folder, use its parent as workspace
+ let workspace_root = if config_parent
+ .file_name()
+ .map(|n| n == ".devcontainer")
</file context>
|
|
||
| // Handle the path argument - it might be a container path or relative path | ||
| let path_str = path.to_string_lossy(); | ||
| let subfolder_path = if path_str.starts_with("/workspace/") || path_str.starts_with("/workspaces/") { |
There was a problem hiding this comment.
P1: Container paths are parsed as valid input, but the flow still canonicalizes the original /workspace/... host path when persisting history, causing a runtime error.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/main.rs, line 85:
<comment>Container paths are parsed as valid input, but the flow still canonicalizes the original `/workspace/...` host path when persisting history, causing a runtime error.</comment>
<file context>
@@ -58,8 +58,56 @@ fn main() -> Result<()> {
+
+ // Handle the path argument - it might be a container path or relative path
+ let path_str = path.to_string_lossy();
+ let subfolder_path = if path_str.starts_with("/workspace/") || path_str.starts_with("/workspaces/") {
+ // Extract subfolder from container path
+ // e.g., "/workspace/vscli/tests" or "/workspaces/vscli/tests"
</file context>
|
|
||
| // Append subfolder if specified | ||
| if let Some(subfolder) = subfolder { | ||
| let subfolder_str = subfolder.to_string_lossy(); |
There was a problem hiding this comment.
P2: Normalize subfolder separators before appending to container_folder; Windows \ separators can produce invalid vscode-remote URI paths.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/workspace.rs, line 207:
<comment>Normalize subfolder separators before appending to `container_folder`; Windows `\` separators can produce invalid `vscode-remote` URI paths.</comment>
<file context>
@@ -192,14 +192,27 @@ impl Workspace {
+
+ // Append subfolder if specified
+ if let Some(subfolder) = subfolder {
+ let subfolder_str = subfolder.to_string_lossy();
+ if !subfolder_str.is_empty() && subfolder_str != "." {
+ // Ensure proper path separator
</file context>
| let subfolder_str = subfolder.to_string_lossy(); | |
| let subfolder_str = subfolder.to_string_lossy().replace('\\', "/"); |
|
Superseded by a fresh reimplementation on current main. The original branch was 5 months stale and couldn't be rebased due to massive codebase changes. |
When specifying a custom devcontainer path with the -c flag, the workspace path is now automatically derived from the devcontainer config location instead of requiring the path to exist on the host filesystem.
This fix addresses the issue where users couldn't open projects with custom devcontainer configurations because the workspace path validation was checking for container paths on the host filesystem.
Changes:
The fix now properly handles:
Fixes #82