formatter: Consider empty RepoTags and RepoDigests as dangling

[vvoland]

• Related to: api: Remove <none> in Repo(Tags|Digests) for >= 1.43 moby/moby#45068
• Depends on: test/cli: Use empty array as empty output of images/json #4050

From API 1.43 version RepoTags and RepoDigests will be empty for dangling images, instead of being an one-item array with magic constant string (<none>:<none>/<none>@<none>).

CLI output is not impacted and will still display <none> strings.

- What I did
Consider images with empty RepoTags and RepoDigests as dangling.

- How I did it

- How to verify it

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[codecov-commenter]

Codecov Report

Merging #4046 (99ad93b) into master (dfb36ea) will increase coverage by 0.00%.
The diff coverage is 0.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4046   +/-   ##
=======================================
  Coverage   59.16%   59.16%           
=======================================
  Files         287      287           
  Lines       24724    24728    +4     
=======================================
+ Hits        14627    14631    +4     
  Misses       9212     9212           
  Partials      885      885           

[vvoland]

So yeah, this fixes the tests, but I'm not sure what was the reason behind this.
With the original changes, a completely empty ImageSummary is also considered a dangling image, which causes it to appear in the docker images output - but obviously it's not a valid image.

Was there a reason this is was not a plain empty slice from the beginning?
Wondering if the fake ImageList call not creating a completely empty slice was a deliberate choice?
Can the server really output empty ImageSummary and the listing code should ignore it?

\cc @thaJeztah

[thaJeztah]

Arf.. was writing up a comment, but didn't put it here. Hold on

[thaJeztah]

Yes, I agree, this seems like it was not intentional (or at least I could not find a direct reason).

Looks like all of these were added as part of the same commit (e779309), that commit was migrated from the moby/moby repository; original one was moby/moby@b2551c6 (moby/moby#32248)

The only possible reasoning I could think of was if it was some attempt to match that the API returns always returns a slice (even if there's no images); the response of the API (tested on docker 17.06 to be sure) is;

curl --unix-socket /var/run/docker.sock 'http://foo/images/json'
[]

But that also doesn't match, because it doesn't return (e.g.) [{}] (single entry).

Other explanation could be to work with the assertion library used at the time; there's a mention that we switched libraries for that at the time; moby/moby#32248 (comment) so perhaps the old one had some issue?

[thaJeztah]

I always get confused on the “ordering” of commits on GitHub;

• so the “test fix” commit was needed to make CI pass after the other commit?
• if that's the case, then the commits should probably be in the reverse order
• but maybe "cleaner" to open a separate PR with only the "test fix" commit to show that it (in itself) does not make CI fail?

GitHub shows the first (?) commit as failing currently;

[vvoland]

Yeah I always get confused about the order too 😄 The order is just a consequence of the fact that I first pushed the empty RepoTags/RepoDigests change and then fixed the failing tests as another commit.

I extracted the test change: #4050 and will rebase this one.

[thaJeztah]

LGTM, thanks!

could you prepare cherry-pick(s) for this one as well?