Background
`buildNoProxyUploadCmd` (`cmd/app/deploy.go:107-116`) does `mkdir -p; rm -f .env; tar xzf -`. Tar extraction overwrites paths present in the archive but leaves untouched paths alone. If a user removes a file from the repo, the file persists on the server across redeploys forever.
This is intentional for `.env.server` (lives one level up at `/opt/conoha/.env.server`) and for named-volume bind mounts. It is unexpected for ordinary repo files: a `rm old-config.json` in the repo does not remove `old-config.json` from the running container's COPY context.
Proposal
Two options:
- Document the trade-off. Add a note to `recipes/single-server-app-noproxy.md` and the README no-proxy section explaining the behavior and recommending `ssh rm ` for one-off cleanups.
- Implement a pre-extract sweep. Remove files in the work dir that aren't in the tar stream, while excluding `.env`, `env.server`, and any registered accessory/volume paths. This is complex to get right.
Option 1 is low-risk and matches v0.1.x behavior. Option 2 is a behavior change worth a separate discussion.
Acceptance
- README and recipe call out the behavior.
- (Optional) follow-up implementing the sweep lands behind an explicit `--clean` flag.
Pointer
- `cmd/app/deploy.go:107-116` — `buildNoProxyUploadCmd`
- `recipes/single-server-app-noproxy.md`
- `README.md` / `README-en.md` / `README-ko.md` ("Two deploy modes" sections)
Surfaced by review on PR #103 (item M5).
Background
`buildNoProxyUploadCmd` (`cmd/app/deploy.go:107-116`) does `mkdir -p; rm -f .env; tar xzf -`. Tar extraction overwrites paths present in the archive but leaves untouched paths alone. If a user removes a file from the repo, the file persists on the server across redeploys forever.
This is intentional for `.env.server` (lives one level up at `/opt/conoha/.env.server`) and for named-volume bind mounts. It is unexpected for ordinary repo files: a `rm old-config.json` in the repo does not remove `old-config.json` from the running container's COPY context.
Proposal
Two options:
Option 1 is low-risk and matches v0.1.x behavior. Option 2 is a behavior change worth a separate discussion.
Acceptance
Pointer
Surfaced by review on PR #103 (item M5).