feat(docker): add Docker client integration #642
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
thwap/thwap-pagesd!642
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/docker-client"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Add Docker client integration for standalone mode (Phase 1 of the Docker roadmap). New
internal/dockerpackage wrapping the Docker SDK client over the Unix socket, with centralized connection-error types and startup socket-accessibility verification.github.com/docker/docker v28.5.2, vendored viago mod vendor.docker.NewClient(socketPath)(empty →/var/run/docker.sock),Ping(ctx)with API-version negotiation,SocketPath(),APIVersion().errorspackage gainsErrDockerUnavailable,ErrDockerSocketMissing,ErrDockerSocketType,ErrDockerPermissionDeniedand wrap helpers with actionable messages (e.g. "add your user to the docker group").Client.CheckAccess(ctx)statically verifies the socket exists, is a Unix socket, is readable/writable, then pings the daemon; fails fast with the typed errors above.Per the standalone deployment model, no
cmd/thwap-pagesdwiring yet — deployer selection (--deployer, #336/#337) is a separate task.Why
Phase 1 requires the Docker client integration before the deployer abstraction (#337) and configuration extensions (#343) can build on it. This is the standalone-mode foundation: transport, error semantics, and startup checks.
Testing
internal/dockertable-driven tests over a fake unix-socket/_pingHTTP server (no real daemon needed)go vet ./...cleango test -race -count=1 ./...full suite passesBreaking Changes
None. Additive package + new error types.
Notes
The dependency is tagged
+incompatibleupstream (no rootgo.mod); the SDK'sclientpackage builds and tests cleanly.go-ansitermis a transitive dep of the Docker SDK viamoby/term.Closes #328
Closes #329
Closes #330
Closes #331
Closes #332
Solid implementation. Code correctness verified against the vendored SDK:
Pinghits the unversioned/_ping(HEAD→GET fallback),ping.APIVersioncomes from theApi-Versionheader, so the fake-server tests are valid andAPIVersion()returns the daemon's advertised version. Error chains (errors.Is) work with the double-%wwraps on go 1.26. Referenced issues #328–#332 all exist and are closed; roadmap checkboxes match. Vendoring follows the repo's existing pattern.Suggestions
internal/docker/docker.go(verifySocket) — access check usesR_OK|W_OK, but connecting to a Unix socket only requires write access; a write-only socket (mode0200) would be usable yet fail the check. ConsiderW_OKonly, matching the docker CLI. Filed as #643.internal/docker/docker.go—Clienthas noClose(); the SDK client holds an HTTP transport and idle connections. Add one for clean daemon shutdown. Filed as #644.internal/docker/docker_test.go— the permission-denied path (ErrDockerPermissionDenied) is untested; the wrap helper is not exercised. Add a test that skips when running as root. Filed as #645.internal/docker/docker.go(CheckAccess/Ping) — no internal timeout; the "fails fast" startup guarantee depends entirely on the caller's context, so a hung daemon could block startup indefinitely. Considercontext.WithTimeout. Filed as #646.No blocking issues. Approving.