Unexpected EOF reading trailer

[estesp]

Unexpected EOF reading trailer

[estesp]

Hmm, do you know what level of manifest-tool code is being used there? I can do a simple inspect of that image using manifest-tool itself:

$ manifest-tool inspect grafana/loki:master-675a5f3-amd64
grafana/loki:master-675a5f3-amd64: manifest type: application/vnd.docker.distribution.manifest.v2+json
      Digest: sha256:5a9b27e5677fdd65e83997ff1572b56712b9a2808ad17eae01033e04dc982f43
Architecture: amd64
          OS: linux
    # Layers: 4
      layer 1: digest = sha256:9123ac7c32f74759e6283f04dbf571f18246abe5bb2c779efcb32cd50f3ff13c
      layer 2: digest = sha256:10989b06f6ec6d647dbff7cc004c708eb13c4d53c9712fc03ee2e7548759cf59
      layer 3: digest = sha256:ad1684fff383fa4d80fdaf3f6079924abae5c09988c5c932fdd5d46da29315f6
      layer 4: digest = sha256:5ed6cf20875895d402892a3fde148051c46d22fcfb5334c466e859ccf6f6bca0

Hard to know what's happening without the ability to reproduce. The actual error looks like it's in the bowels of an HTTP interaction, which is simply using the Go HTTP client libraries. Is this repeatable or is it random? (Edit: I see you mention it may not happen if you re-run; that's strange)

Thanks!

[rfratto]

As a quick update, we've pruned even more images down to around ~800 tags and now manifest-tool has been working consistently. We're happy with the solution for now but I'm concerned about passing the arbitrary threshold into having problems with this again, especially if our rate of commits grows.

Hmm, do you know what level of manifest-tool code is being used there?

I'm not sure what you mean by level here, could you explain? If it helps, this is the plugin that is using manifest-tool.

Is this repeatable or is it random? (Edit: I see you mention it may not happen if you re-run; that's strange)

I don't have enough evidence to prove this is the behavior 100% of the time, but the pattern appears to be: if the first run fails, the re-run succeeds.

At first I thought it might have been a timing issue (i.e., the images didn't exist on Docker Hub when manifest-tool runs), but I was able to verify that all arch-specific images existed before one instance of manifest-tool that failed.

[estesp]

@rfratto I finally realized what this might be--the initial code for this project came from an early version of skopeo, which had a general inspect command which included pulling the entire tag list for an image into the raw JSON response; manifest-tool doesn't use this information, but it is accessible from the raw JSON data. I think it would be reasonable to remove this "tag query" (which is another round trip to the registry that isn't really necessary) from manifest-tool which would probably fix your issue.

The specific line that asks the registry for a list of all tags for the found image is here. One quick and easy test to see if this is the issue is to remove that line and set the taglist to empty. This only affects the -raw json output and is not used for the actual support of manifest lists.

[tboerger]

Even if there is something wrong within the drone plugin I'm happy to help out there.

[estesp]

This is solved by #90.