-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
image/list: Add --tree
flag
#4982
Conversation
1b66af3
to
a4c71cf
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4982 +/- ##
==========================================
- Coverage 61.51% 60.94% -0.57%
==========================================
Files 303 304 +1
Lines 21130 21331 +201
==========================================
+ Hits 12998 13001 +3
- Misses 7203 7400 +197
- Partials 929 930 +1 |
cli/command/image/tree.go
Outdated
func runTree(ctx context.Context, dockerCLI command.Cli, opts treeOptions) error { | ||
images, err := dockerCLI.Client().ImageList(ctx, imagetypes.ListOptions{ | ||
All: opts.all, | ||
ContainerCount: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs: moby/moby#47501
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have the per-image list of containers now, correct? In that case; do we still need that PR? I was always a slight bit on the fence on that one, as only a number of containers didn't provide a ton of useful information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have, but it's only filled if the ContainerCount
option is set (we can still change that though).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I remove the Usage
column for now?
a4c71cf
to
7a5dc95
Compare
4662670
to
6ec9439
Compare
cd11dc8
to
9cf3aac
Compare
9cf3aac
to
746f598
Compare
Combined multiple images with the same target under one entry: tree.mp4cc @jalonsogo |
c0aec20
to
2210865
Compare
44c9a10
to
0fd1cd8
Compare
0fd1cd8
to
384e4b8
Compare
af28277
to
2b46c60
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
So, I just bugged @jalonsogo for advice, and got a couple of guildelines to follow, tldr:
I made |
Nice! I didn't know about right-alined numbers, but it makes sense – this way, the decimal places are aligned, which also makes it easier to parse the table and find larger numbers |
Ah, yes, I like that variant! The numbers have always been a bit tricky, and I know we (still) have some bugs in those; the intent was to have a fixed number of decimals so that values align (and pick the most appropriate unit to make that happen), but there's still some bugs there (see #3091) |
OK; one more thing I noticed (but maybe something to also fix on the daemon side not sure?) is the order in which variants are shown; Output with only arm64; docker image ls --tree
Image ID Disk usage Content size Used
alpine:latest 0a4eaa0eecf5 13.6MB 4.09MB
├─ linux/arm64/v8 24ba417e25e7 13.6MB 4.09MB
├─ linux/amd64 eddacbc7e24b 0B 0B
├─ linux/arm/v6 5c7e326e3c8a 0B 0B
├─ linux/arm/v7 fda9b1b812b2 0B 0B
├─ linux/386 fa66aa594ffa 0B 0B
├─ linux/ppc64le a01843eb870e 0B 0B
├─ linux/riscv64 e99a4d9aa9f9 0B 0B
└─ linux/s390x 14da06d3a895 0B 0B Pull s390x; docker image pull --platform=linux/s390x alpine New output; docker image ls --tree
Image ID Disk usage Content size Used
alpine:latest 0a4eaa0eecf5 25.5MB 7.55MB
├─ linux/s390x 14da06d3a895 11.9MB 3.46MB
├─ linux/arm64/v8 24ba417e25e7 13.6MB 4.09MB
├─ linux/amd64 eddacbc7e24b 0B 0B
├─ linux/arm/v6 5c7e326e3c8a 0B 0B
├─ linux/arm/v7 fda9b1b812b2 0B 0B
├─ linux/386 fa66aa594ffa 0B 0B
├─ linux/ppc64le a01843eb870e 0B 0B
└─ linux/riscv64 e99a4d9aa9f9 0B 0B I wondered where the sort-order is based on; perhaps sorting is happening on "Created" date, but it looks like we omit that in the new view; docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
docker-dev latest e1ca8a3ea183 6 hours ago 2.2GB
localhost:5001/owner/name latest 0fea7086b9c0 8 hours ago 17.2MB
docker-cli-dev latest 88c125e27aee 3 days ago 749MB
golang 1.22 2bd56f00ff47 8 days ago 1.21GB
moby/buildkit buildx-stable-1 0a5641c72659 3 weeks ago 298MB
docker dind a69069397655 3 weeks ago 491MB
alpine latest 0a4eaa0eecf5 3 weeks ago 25.7MB
registry 3.0.0-beta.1 efb271da5cd0 5 weeks ago 61.8MB
nginx alpine 208b70eefac1 7 weeks ago 68.4MB
registry 2 12120425f07d 10 months ago 36.1MB
docker 20.10-cli 2967f0819c84 15 months ago 209MB
registry 2.7 169211e20e2f 2 years ago 35.4MB
registry 2.6 c4bdca23bab1 4 years ago 38.5MB Maybe we should
Final thought; some what related to moby/moby#48264 (comment) - wondering if we should have
|
Variants are sorted by the "availability" so that present variants are always on top. |
// Mark top-level parent image as used if any of its subimages are used. | ||
details.Used = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot now; did we also add the list of container-id's that used it somewhere? (Maybe not to be printed by default for sure)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the ImageData
has a list of containers. It's only available in the manifest summary though.
Also, see: #4982 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree with @laurazard that maybe some things could be refactored, but looks like a good start to me :)
One design consideration though: I tend to think that some whitespace could go a long way in making the output easier to parse (since this is for humans more than for machines, right?). For example when using the command a couple times i find it hard to visually parse the beginning of the output from the command that the user typed, and also to read the column titles from the image names listed since they're all back to back (and title+first image name are both bold).
Maybe to separate column titles from the column contents they could:
- have some whitespace around them, separating them from contents and the command the user typed;
- be a different color;
- have a line under them like an old school table;
Just throwing some thoughts out there. WDYT here @jalonsogo? Maybe some discussions have already been made around this, if so feel free to ignore this comment :)
Given the experimental nature, we can definitely iterate on these things. It'd also be nice to consolidate our design and usage of columns/tables etc amongst all our other commands as well
This command has nice (imho) whitespace in it's output, for example
![Screenshot 2024-08-16 at 12 52 32](https://private-user-images.githubusercontent.com/47751006/358560349-9b850cd6-39fc-47b2-a82f-458f8af826a9.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU4MTk0NDAsIm5iZiI6MTcyNTgxOTE0MCwicGF0aCI6Ii80Nzc1MTAwNi8zNTg1NjAzNDktOWI4NTBjZDYtMzlmYy00N2IyLWE4MmYtNDU4ZjhhZjgyNmE5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA5MDglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwOTA4VDE4MTIyMFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWU1MDdjYzg1MDg1M2JlMDc1NjNiNjMzZDg4ZmNjNzUyMzUyMzg4ZTc3ZDcyNzBmNzEzNjUyMDVkYThkMmVkZjYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.tCMGis9opRRWPGK5WVyzmZS9XenB0vEuNpEQRD810Zg)
Initially there was a newline between header and the first item, but removed it after a small discussion here: #4982 (comment) Regarding the newline before the command content.. I think it might work: |
9e14c08
to
963307a
Compare
Removed the EDIT: Also an alternative PR that allows the |
963307a
to
835cad9
Compare
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
835cad9
to
a9b78da
Compare
container-count
parameter moby/moby#47501Add
--tree
flag todocker image list
Update:
![image](https://private-user-images.githubusercontent.com/5046555/355429364-e7dba6e5-6065-4dcb-a575-3642e3fbe6d3.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU4MTk0MzksIm5iZiI6MTcyNTgxOTEzOSwicGF0aCI6Ii81MDQ2NTU1LzM1NTQyOTM2NC1lN2RiYTZlNS02MDY1LTRkY2ItYTU3NS0zNjQyZTNmYmU2ZDMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkwOCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MDhUMTgxMjE5WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OTk5ZmNmMWIyZjFiMGI3MGViYTU4ODg3ODVjZWQxOGVhZDAyZjk0YWI1MTEwMDc0NWM4NDU2MzdiMTM5ZGQ1OSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.4FLTS9WQpk69XpcI177ZQuw67B0aSneJho7RKiHiGhs)
Added some spacing around images:
- Description for the changelog