menzeljonas/stackpilot
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
106 Commits 2 Branches 0 Tags
052a85067b79845c55f1ac5650ab31553d75dab8
Commit Graph
3 Commits
Author SHA1 Message Date
menzeljandClaude Opus 5 6c62803dc7 Stop leaking helper containers that fail to start (0.66.1)
CI / check (push) Successful in 13m17s
Details
CI / build-and-push (push) Successful in 2m20s
Details 
docker-py's containers.run(remove=True) only removes a container after it
ran. A helper whose start failed - an NFS destination refusing the mount -
stayed behind in "Created", holding the destination's volume. Every Test
click and scheduled backup added one (a user found 18), the volume could
not be deleted even with everything stopped, and changed mount options
never took effect because the volume could not be recreated with them.

- docker_client.run_container: create, start, wait, collect output and
  always remove, also when the start fails; pulls a missing image. Used
  for NFS destination I/O, bind-path inspection, the volume wipe before a
  restore and the Trivy scanner.
- Every helper container is labelled stackpilot.helper; on startup the
  stopped ones are removed, together with anything left on an NFS
  destination volume by older versions.
- When an NFS destination's options change, stopped containers holding
  its volume are removed before it is recreated; a running one is now a
  clear error instead of silently keeping the old options.
- A refused mount explains itself: NFS enabled and reachable from the
  Docker host, NFSv3 needing rpcbind and mountd, and nfsvers=4 needing
  only port 2049.
- The scanner waits for Trivy's own 10-minute timeout instead of giving
  up after the default client's 60 seconds.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-18 14:14:32 +02:00
menzeljandClaude Opus 5 f766ded528 Stop long prunes failing with a bare 500 (0.60.1)
CI / check (push) Successful in 13m35s
Details
CI / build-and-push (push) Successful in 2m10s
Details 
A prune that deletes a lot of data (image prune -a in particular) easily
runs past docker-py's 60s read timeout. requests' ReadTimeout is not a
DockerException, so it slipped past safe_call and the UI only showed
"Request failed with status code 500".

Prunes now use a client with a 540s timeout (below nginx's 600s
proxy_read_timeout), and safe_call turns transport timeouts and
connection errors into DockerError, so they surface as a 502 with a
message.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-18 09:39:47 +02:00
menzeljandClaude Opus 4.8 f732cb080b Initial commit: StackPilot Phase 1 (Core) 
Self-hosted Docker Compose manager.
- Backend: FastAPI + docker-py + SQLite (JWT auth, file-first stacks,
  lifecycle, live status, WebSocket logs, docker-run converter, audit log)
- Frontend: React + Vite + Tailwind (login/setup, dashboard, stacks,
  stack detail, Monaco editor, dark/light theme)
- Deployment: docker-compose.yml, Dockerfiles, nginx reverse proxy

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-07 16:04:58 +00:00