Alex Blank
29a12bb102
- Add expand_container_path() helper that resolves ~/ and $HOME/ prefixes
- Add get_manifest_home_dir() to compute /home/{user.name} or /root from manifest
- Set ENV HOME=... and ENV USER=... in generated Dockerfile for runtime compatibility
- Pass home_dir through instance creation and startup pipeline
- Expand mount targets in apply_resolved_profile() for regular profile mounts
- Expand mapping targets in _resolve_git_mount_mappings() for git mounts
- Expand working_directory and volume targets in _modify_compose_file()
- Update _prepare_manifest_instance to return home_dir alongside image tag
- Fetch tool_type early in start_instance to determine home_dir before profile application
Quality gates: pytest 188 passed, frontend typecheck clean
Addresses: home-path-expansion
2.1 KiB
2.1 KiB
Spec: ~ / $HOME Expansion in Mount Paths
Requirements
Functional
- FR-1:
~in mount target paths MUST be expanded to the container's home directory. - FR-2:
$HOMEin mount target paths MUST be expanded to the container's home directory. - FR-3: For manifest-based tools with
user.name, home MUST be/home/{user.name}. - FR-4: For manifest-based tools without user block, home MUST be
/root. - FR-5: For legacy tool types, home MUST be
/root. - FR-6: Git mount
mapping.target_pathMUST support~and$HOME. - FR-7: The generated Dockerfile MUST set
HOMEenv var.
Non-Functional
- NFR-1: No database schema changes.
- NFR-2: No frontend changes.
- NFR-3: Existing profiles without
~MUST continue working.
API Contracts
No API changes. Resolution happens server-side during compose generation.
Scenarios
Scenario 1: pi-agent with ~ mount
Given a Config Profile with:
{"mounts": [{"target": "~/workspace", "mode": "rw", "files": {}}]}
And a pi-agent manifest with user.name = "user"
When the profile is applied
Then the compose file contains /home/user/workspace as the mount target.
Scenario 2: Legacy tool with $HOME mount
Given a Config Profile with:
{"mounts": [{"target": "$HOME/config", "mode": "ro", "files": {}}]}
And a legacy tool type (no manifest)
When the profile is applied
Then the compose file contains /root/config as the mount target.
Scenario 3: Git mount with ~ target
Given a Config Profile with:
{"git_mounts": [{"remote_url": "...", "mappings": [{"source_path": ".", "target_path": "~/repo"}]}]}
And a manifest with user.name = "user"
When the profile is applied
Then the compose file contains /home/user/repo as the mount target.
Test Strategy
- Unit test
expand_container_pathwith~,$HOME, absolute paths, relative paths - Unit test
get_manifest_home_dirwith user block, without user block - Integration test: profile with
~mount applied to pi-agent instance - Integration test: profile with
$HOMEmount applied to legacy instance