Address review feedback on pre_start hook image resolution:
1. GetDependentImages now skips a hook image equal to the service image
(resolved via GetImageNameOrDefault), so `config --images` no longer
prints a duplicate line and pullRequiredImages no longer schedules a
redundant pull for it.
2. pullRequiredImages (up/create path) now dedups dependent images by
reference via a `scheduled` set, so several hooks/services sharing the
same missing image don't schedule concurrent redundant pulls. The hook
pass moved to a helper (addPreStartHookPulls) to keep complexity in check.
3. The `pull` command no longer skips hook images under `pull_policy: build`.
A hook image is a registry image that can't be built, so only `never`
justifies skipping it — making `pull` consistent with the `up` path.
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
pre_start hooks run as ephemeral init containers with their own image
(ServiceHook.Image), but that image was ignored by image resolution:
`config --images` didn't list it, `pull` didn't fetch it, and `up` failed
at runtime with "No such image" when it wasn't already present locally.
Add a GetDependentImages helper that returns a service's pre_start hook
images, and use it wherever service images are collected/pulled:
getLocalImagesDigests, pullRequiredImages (up path), the pull command, and
`config --images`. Hook images inherit the parent service pull policy.
post_start/pre_stop hooks run via ExecCreate inside the service container
and never use hook.Image, so they are intentionally out of scope.
Digest resolution/locking (--resolve-image-digests / --lock-image-digests)
is not covered: compose-go's WithImagesResolved only resolves service.Image
(needs an upstream change), and the --lock-image-digests override merges
pre_start by concatenation, which would duplicate hooks.
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
Provider info and error messages containing newlines broke the TTY
progress display (timer drifting to a new line, broken cursor
movement). Extract only the first line for progress events via
firstLine(). Full messages remain available through the provider's
own debug message type.
Skip provider services during watch rebuild convergence by adding a
SkipProviders flag to CreateOptions, set only by the watch rebuild
path. This prevents unnecessary re-invocation of providers on every
file change while preserving normal provider execution for all other
commands (up, create, run, scale).
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
Also update TestDefaultNetworkSettings:
Test that the network with the highest priority is returned as
"primary" network, and other networks as extra networks.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Currently when using models, the final message is 'confugiring' which could let users think the DMR configuration is still pending
Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>
# Conflicts:
# pkg/api/event.go
Most files already grouped imports into "stdlib -> other -> local",
but some files didn't. The gci formatter is similar to goimports, but
has better options to make sure imports are grouped in the expected
order (and to make sure no additional groups are present).
This formatter has a 'fix' function, so code can be re-formatted auto-
matically;
golangci-lint run -v --fix
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit adds a new LoadProject method to the Compose service API,
allowing SDK users to programmatically load Compose projects with full
control over the loading process.
Changes:
1. New API method (pkg/api/api.go):
- LoadProject(ctx, ProjectLoadOptions) (*types.Project, error)
- ProjectLoadOptions struct with all loader configuration
- LoadListener callback for event notifications (metrics, etc.)
- ProjectOptionsFns field for compose-go loader options
2. Implementation (pkg/compose/loader.go):
- createRemoteLoaders: Git and OCI remote loader setup
- buildProjectOptions: Translates ProjectLoadOptions to compose-go options
- postProcessProject: Service filtering, labels, resource pruning
3. Unit test (pkg/compose/loader_test.go):
- Tests basic project loading functionality
- Verifies ProjectOptionsFns with cli.WithoutEnvironmentResolution
4. Mock update (pkg/mocks/mock_docker_compose_api.go):
- Added LoadProject to mock interface
Key design decisions:
- LoadListener pattern keeps metrics collection in CLI, not SDK
- ProjectOptionsFns exposes compose-go options directly (e.g., cli.WithInterpolation(false))
- Post-processing in SDK: labels, service filtering, resource pruning
- Environment resolution NOT in SDK (command responsibility)
- Compatibility mode handling (api.Separator)
Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>
This commit prepares the Compose service for SDK usage by abstracting away
the hard dependency on command.Cli. The Docker CLI remains the standard path
for the CLI tool, but SDK users can now provide custom implementations of
streams and context information.
Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>
This commit introduces WithMaxConcurrency and WithDryRun to replace direct mutators on composeService
commands and flags are translated into a set of functional parameters which are eventually applied
as a ComposeService is created just before being actually used by a command
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
This warning was added in [moby@4a8b3ca] to print a warning when building
Linux images from a Windows client. Window's filesystem does not have an
"executable" bit, which mean that, for example, copying a shell script
to an image during build would lose the executable bit. So for Windows
clients, the executable bit would be set on all files, unconditionally.
Originally this was detected in the client, which had direct access to
the API response headers, but when refactoring the client to use a common
library in [moby@535c4c9], this was refactored into a `ImageBuildResponse`
wrapper, deconstructing the API response into an `io.Reader` and a string
field containing only the `OSType` header.
This was the only use and only purpose of the `OSType` field, and now that
BuildKit is the default builder for Linux images, this warning didn't get
printed unless BuildKit was explicitly disabled.
This patch removes the warning, so that we can potentially remove the
field, or the `ImageBuildResponse` type altogether.
[moby@4a8b3ca]: 4a8b3cad60
[moby@535c4c9]: 535c4c9a59
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
when building a image, by default attestation are generated and modify the image ID which trigger a container recreation on up, run command even if there isn't any changes on the image content itself
Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>
