fix(image): don't treat digest-only images as dangling in list output by mohithshuka · Pull Request #6960 · docker/cli

mohithshuka · 2026-04-29T13:14:09Z

Problem

docker images was hiding images that have a digest but no tag, treating
them as dangling. This caused valid images to silently disappear from
default output.

The local isDangling function in list.go was missing the
len(img.RepoDigests) == 0 check, so any image with no tags but a valid
digest was incorrectly filtered out.

Fix

Align list.go's isDangling with the definition already correct in
formatter/image.go — an image is only dangling if it has both no tags
AND no digests.

Before / After

Before: Images with digest but no tag silently hidden from docker images
After: Those images appear in output as expected

Fixes #6650

Fixes #24643 --kernel-memory was deprecated in v20.10 and removed in v23.0. Add deprecation callouts to both the options table and the Kernel memory constraints section of the run reference page.

The --filter flag for 'docker volume prune' previously only showed 'label=<label>' as an example, not mentioning the negation form 'label!=<label>', even though it is valid and supported by the daemon. Fixes docker#6918 Signed-off-by: mohithshuka <153504854+mohithshuka@users.noreply.github.com>

When a port is bound on both 0.0.0.0 and ::, hide the IPv6 entry and show only the IPv4 entry to reduce noise in docker ps output. Before: 0.0.0.0:8080->80/tcp, :::8080->80/tcp After: 0.0.0.0:8080->80/tcp Fixes docker#6869

The --archive (-a) flag description was misleading. Updated to clarify that it preserves uid/gid from the source, and that it only takes effect when copying files TO a container (not from). Fixes docker#6870

Signed-off-by: mohithshuka <153504854+mohithshuka@users.noreply.github.com>

The local isDangling in list.go was missing the RepoDigests check, causing images with a digest but no tag to be incorrectly filtered from default 'docker images' output. Align with formatter.isDangling. Fixes docker#6650

Copilot

Pull request overview

Fixes incorrect filtering in docker images so digest-only images are not treated as dangling (and therefore not hidden), alongside several CLI help/doc updates and a docker ps port-formatting tweak.

Changes:

Fix cli/command/image/list.go dangling detection to require both no tags and no digests.
Adjust docker ps port rendering to suppress duplicate IPv6 wildcard entries when an equivalent IPv4 wildcard mapping exists.
Update CLI help text and docs for docker cp --archive, docker run --kernel-memory deprecation, and volume prune filter examples.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
docs/reference/run.md	Marks `--kernel-memory` as deprecated/removed and adds a deprecation callout in the kernel memory section.
docs/reference/commandline/cp.md	Updates generated docs text for `docker cp --archive` behavior.
docs/reference/commandline/container_cp.md	Updates generated docs text for `docker container cp --archive` behavior.
cli/command/volume/prune.go	Expands `--filter` help example to include `label!=...`.
cli/command/image/list.go	Fixes dangling filtering so digest-only images aren’t removed from default `docker images` output.
cli/command/formatter/container.go	Suppresses duplicate IPv6 wildcard port mappings in `DisplayablePorts`.
cli/command/container/cp.go	Updates `--archive` flag help text to clarify behavior.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-29T13:20:03Z

+	// Pre-pass: record which (hostPort, privatePort, proto) tuples have an
+	// IPv4 wildcard (0.0.0.0) binding. Used below to suppress the matching
+	// IPv6 wildcard (::) entry, avoiding duplicate output such as:
+	//   0.0.0.0:8080->80/tcp, :::8080->80/tcp
+	// See: https://github.com/docker/cli/issues/6869
+	type mappingKey struct {
+		hostPort    uint16
+		privatePort uint16
+		proto       string
+	}
+	ipv4Bindings := make(map[mappingKey]bool)
+	for _, port := range ports {
+		if port.IP.String() == "0.0.0.0" && port.PublicPort != 0 {
+			ipv4Bindings[mappingKey{port.PublicPort, port.PrivatePort, port.Type}] = true
+		}
+	}
+


The PR title/description focus on fixing docker images filtering of digest-only images, but this PR also includes unrelated changes (port formatting suppression in DisplayablePorts, docs updates for --kernel-memory, docker cp flag text, and volume prune filter help). Please either split these into separate PRs or update the PR title/description to accurately describe the full scope, to make review and release notes clearer.

Copilot · 2026-04-29T13:20:04Z

+	// Pre-pass: record which (hostPort, privatePort, proto) tuples have an
+	// IPv4 wildcard (0.0.0.0) binding. Used below to suppress the matching
+	// IPv6 wildcard (::) entry, avoiding duplicate output such as:
+	//   0.0.0.0:8080->80/tcp, :::8080->80/tcp
+	// See: https://github.com/docker/cli/issues/6869


The newly added comment examples show IPv6 wildcard bindings as :::8080->80/tcp, but the actual formatting produced here uses net.JoinHostPort, which renders IPv6 as [::]:8080->80/tcp (see existing tests expecting [::1]:...). Please update the examples so they match real output and avoid confusion when reading this code.

Copilot · 2026-04-29T13:20:04Z

@@ -373,6 +391,18 @@ func DisplayablePorts(ports []container.PortSummary) string {
 		portKey := port.Type
 		if port.IP.IsValid() {
 			if port.PublicPort != current {
+				// Suppress the IPv6 wildcard entry when an IPv4 wildcard
+				// entry already covers the same (hostPort, privatePort, proto)
+				// tuple. This merges:
+				//   0.0.0.0:8080->80/tcp, :::8080->80/tcp
+				// into the cleaner:
+				//   0.0.0.0:8080->80/tcp
+				if port.IP.Is6() && !port.IP.Is4In6() && port.IP.IsUnspecified() {
+					key := mappingKey{port.PublicPort, port.PrivatePort, port.Type}
+					if ipv4Bindings[key] {
+						continue
+					}
+				}


This change introduces new behavior (suppressing the IPv6 wildcard :: mapping when an equivalent IPv4 wildcard 0.0.0.0 mapping exists), but there is no test coverage for the duplicate-output case (e.g., 0.0.0.0:8080->80/tcp + [::]:8080->80/tcp). Please add/extend a TestDisplayablePorts case to lock in the intended suppression behavior and prevent regressions.

Copilot · 2026-04-29T13:20:04Z

+	if len(img.RepoTags) == 0 && len(img.RepoDigests) == 0 {
 		return true
 	}
 	return len(img.RepoTags) == 1 && img.RepoTags[0] == "<none>:<none>" && len(img.RepoDigests) == 1 && img.RepoDigests[0] == "<none>@<none>"


This PR changes the CLI-side dangling filtering so digest-only images are no longer removed from default docker images output. There are existing tests/goldens in cli/command/image/list_test.go (e.g., list-command-filter-dangling.no-dangling-filter.golden) that currently expect digest-only images to be hidden; those fixtures should be updated so the tests reflect the corrected behavior (digest-only images should remain visible when --all is not set and dangling filter is absent/false).

thaJeztah · 2026-05-04T13:49:17Z

This needs a rebase as it has unrelated commits in the PR, but I think this was an intentional change;

docker images --tree: hide both untagged and dangling images by default #5924

Daryes · 2026-05-23T20:11:02Z

This needs a rebase as it has unrelated commits in the PR, but I think this was an intentional change;
* [docker images --tree: hide both untagged and dangling images by default #5924](https://github.com/docker/cli/pull/5924)

I've read the so-called "intentional" change, and I'm asking myself some serious questions :

dangling images were visible without the -a parameter (or some of them, I had multiple <none>:<none> visible immediately)
the builder, legacy or not, is not the only one able to create untagged image. An image with the latest tag, replaced by a newest version on a docker pull will lose its tag, replaced by <none>
same when rebuilding the same image, buildx, which is not legacy, will untag the older image.
docker system prune is not enough for untagged images, which is the problem : if you don't see them, you won't remove them. Beside, I had my share of horror stories with prune up to the point of not using it blindly in production, if not at all.
docker has no automatic removal of untagged image (dangling or not). Hiding them from the user is a very bad move. Many of them does not have enough knowledge of docker to understand those fine prints. Hiding all untagged images just because, even the legit one, is a recipe for disaster.
the change itself is seriously breaking from years of consistent behaviors, while bringing no real reason on the table.

Btw, just curious, but what is usually the review process for any breaking change on a critical component ?

maxweisspoker · 2026-05-27T09:12:30Z

This needs a rebase as it has unrelated commits in the PR, but I think this was an intentional change;

docker images --tree: hide both untagged and dangling images by default #5924

I'd also like to know what the process was for introducing changes like this that fundamentally change the expected behavior of important commands. I also had several hours of tearing my hair out trying to figure out why my untagged images weren't showing, and also have several pipelines using the cli to list images that broke with that change.

Who wanted that change? What was the process for deciding if it was necessary? Same questions for the format change that was introduced, although at least that one has a configuration setting to revert back to the better behavior.

mohithshuka and others added 6 commits April 9, 2026 17:45

docs: add deprecation notice for --kernel-memory flag

0015f6c

Fixes #24643 --kernel-memory was deprecated in v20.10 and removed in v23.0. Add deprecation callouts to both the options table and the Kernel memory constraints section of the run reference page.

fix(cp): clarify --archive flag only applies when copying to container

044dea2

The --archive (-a) flag description was misleading. Updated to clarify that it preserves uid/gid from the source, and that it only takes effect when copying files TO a container (not from). Fixes docker#6870

docs: update docker cp --archive flag description to match source

e2abd26

Signed-off-by: mohithshuka <153504854+mohithshuka@users.noreply.github.com>

Copilot AI review requested due to automatic review settings April 29, 2026 13:14

mohithshuka requested review from a team and thaJeztah as code owners April 29, 2026 13:14

Copilot started reviewing on behalf of mohithshuka April 29, 2026 13:14 View session

Copilot AI reviewed Apr 29, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(image): don't treat digest-only images as dangling in list output#6960

fix(image): don't treat digest-only images as dangling in list output#6960
mohithshuka wants to merge 6 commits into
docker:masterfrom
mohithshuka:fix/docker-images-readable-output

mohithshuka commented Apr 29, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 29, 2026

Uh oh!

Copilot AI Apr 29, 2026

Uh oh!

Copilot AI Apr 29, 2026

Uh oh!

Copilot AI Apr 29, 2026

Uh oh!

thaJeztah commented May 4, 2026

Uh oh!

Daryes commented May 23, 2026 •

edited

Loading

Uh oh!

maxweisspoker commented May 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

mohithshuka commented Apr 29, 2026

Problem

Fix

Before / After

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

thaJeztah commented May 4, 2026

Uh oh!

Daryes commented May 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maxweisspoker commented May 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Daryes commented May 23, 2026 •

edited

Loading