aws-samples / aws-samples/sample-amazon-bedrock-agentcore-coding-agents
Track S3 Files performance before placing Git worktrees on the mount
- Dominant language
- Python
- Stars
- 8
- Forks
- 10
- Avg merge
- 7d 13h
- Merged PRs (30d)
- 1
Description
## Context
Lab 2 needs one isolated checkout per work item. We evaluated placing linked Git worktrees on the Workshop Studio S3 Files mount so they would be visible from both the coordinator host and role Runtimes.
## Measured behavior
On a deployed Workshop Studio environment, using the workshop repository at 353 files:
| Operation | Local `/tmp` | `/mnt/s3files` |
|---|---:|---:|
| `git worktree add` | 30 ms | 5,492 ms |
| five `git status` calls | 81 ms | 2,015 ms |
| `git worktree remove` | 20 ms | 4,713 ms |
The S3 Files mount also reported `local_lock=none`. Git worktrees update shared administrative metadata and rely on lock behavior, so the latency and lock semantics make the mount a poor execution filesystem for this path.
## Current decision
- Keep coordinator worktrees on local disk under `WORKSHOP_RUNS_DIR` (the deployed coordinator uses `/tmp/workshop-runs`).
- Expand each tracked source archive under Runtime-local `/tmp`, create `worktree-` there, run the role, and return one tracked result archive.
- Keep `/mnt/s3files` for the Lab 1 interactive shared-storage exercise, not as the Lab 2 execution or run-state filesystem.
- Never transfer `.git`, dependency directories, virtual environments, or caches across the Runtime boundary.
## Follow-up
Re-benchmark if the S3 Files client or mount semantics change. Reconsider a mount-backed worktree root only when add/status/remove latency is close enough to local disk for an attendee workflow and Git locking is explicitly supported. Until then, local ephemeral worktrees plus bounded source archives are the supported design.
Contributor guide
Research direction
Start by reproducing the documented `git worktree add`, repeated `git status`, and `git worktree remove` measurements on local disk and `/mnt/s3files` in a deployed Workshop Studio environment. Compare latency and verify whether Git locking is explicitly supported; done means recording updated results and revisiting the documented mount-backed worktree decision if the criteria are met.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, git
- Domain
- cloud, infrastructure
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100