Documentation
¶
Overview ¶
Package docker holds the local docker-compose shell-out primitives the stack / project / migrate commands drive. Seams (RunComposeFn / RunComposeEnvFn) let tests stub the shell-out.
Index ¶
Constants ¶
const ComposeFile = "compose.w17.yaml"
ComposeFile is the tool-owned compose file. The sibling `compose.yaml` is the developer's extension point and `include:`s this one.
Variables ¶
var CaptureComposeFn = realCaptureCompose
CaptureComposeFn is the seam tests stub; production runs realCaptureCompose. It captures a compose subcommand's stdout (e.g. `ps --format json`) for programmatic inspection rather than streaming it to the terminal. Stderr is discarded — callers treat any error as "no data" and degrade gracefully.
var RunComposeEnvFn = realRunComposeEnv
RunComposeEnvFn is the seam tests stub; production runs realRunComposeEnv.
var RunComposeFn = realRunCompose
RunComposeFn is the seam tests stub; production runs realRunCompose.
Functions ¶
func FileArgs ¶
FileArgs returns the `-f <file>` docker compose should be driven with for the project at root.
Without it, compose picks its own default — `compose.yaml` in the working directory — and in a repo that had one BEFORE w17 arrived, that is somebody else's file. A consumer's `stack up` started building their unrelated services and failed pulling an image w17 never heard of. Two correct decisions produced it: codegen refuses to overwrite an existing compose.yaml, and the stack is driven from the project root. Neither is wrong; the intersection had no way to say "just mine".
So the choice is made here rather than left to discovery:
- compose.yaml INCLUDES ComposeFile → it is the stub (or a developer's extension of it), and driving it is what brings both in;
- otherwise → ComposeFile alone. A compose.yaml that does not include ours is not ours to start.
For a greenfield project, where codegen wrote the stub itself, this is the behaviour that was already there.
Types ¶
This section is empty.
Source Files