mirror of
https://github.com/docker/compose.git
synced 2026-10-12 02:13:08 +00:00
hiroto.toyoda
20717bab83
`down --rmi` removed every dangling image for the project unconditionally,
while its tagged-image counterpart (ImagesToPrune) already skips a service
no longer in the project unless --remove-orphans is set. `down --rmi local`
on a project with an orphaned service therefore kept the tagged image but
deleted its dangling ones - an inconsistent result for one command.
Extract the "list a project's dangling images, remove what a keep predicate
doesn't spare, tolerate individual failures" logic - which down.go and
watch.go's pruneDanglingImagesOnRebuild had each partially and divergently
implemented - into one shared composeService.removeDanglingImages,
parallelized via errgroup like the rest of the codebase's bulk removals.
down.go's keep now mirrors ImagesToPrune's own RemoveOrphans/GetService
check; watch.go keeps its existing built-IDs check, behavior unchanged.
The removal fan-out now also honors --parallel via eg.SetLimit(s.maxConcurrency),
matching push.go/pull.go, instead of always running unbounded. Fixed
TestWatch_Sync's composeService{} literal to set maxConcurrency: -1
(NewComposeService's own default) - the zero value means "allow zero
concurrent goroutines" to errgroup, not "unlimited", and was silently
relying on maxConcurrency being unused before this change.
Signed-off-by: hiroto.toyoda <[email protected]>