Artifact .zip is actually a .tar.gz

[yarikoptic]

Original issue where I reported was

• Broken artifact? bids-standard/bids-validator#248

What I observe is that having https://github.com/bids-standard/bids-validator/blob/main/.github/workflows/docker-build-push.yml#L44

      - name: Build ${{ startsWith(github.ref, 'refs/tags/') && 'and push' || '' }} ${{ steps.meta.outputs.tags }}
        uses: docker/build-push-action@v6
        with:
          context: .
          push: ${{ startsWith(github.ref, 'refs/tags/') }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

(I believe that is the step) we have artifact uploaded to e.g. https://github.com/bids-standard/bids-validator/actions/runs/17406110898?pr=247

which if I download in Chromium 138.0.7204.183 (Official Build) built on Debian GNU/Linux 13 (trixie) (64-bit)

I get prompted it to be bids-standard~bids-validator~QREREU.dockerbuild.zip but after download I see that it is actually

❯ zip -l bids-standard\~bids-validator\~QREREU.dockerbuild.zip
	zip warning: missing end signature--probably not a zip file (did you
	zip warning: remember to use binary mode when you transferred it?)
	zip warning: (if you are trying to read a damaged archive try -F)

zip error: Zip file structure invalid (bids-standard~bids-validator~QREREU.dockerbuild.zip)

but a

❯ tar -tzvf bids-standard\~bids-validator\~QREREU.dockerbuild.zip
drwxr-xr-x 0/0               0 1969-12-31 19:00 blobs/
drwxr-xr-x 0/0               0 1969-12-31 19:00 blobs/sha256/
-r--r--r-- 0/0           12634 1969-12-31 19:00 blobs/sha256/035997bd4ec21c47a35f22e518d8f881cc079825bd86bb4006c1487a7904169a
-r--r--r-- 0/0            1228 1969-12-31 19:00 blobs/sha256/16b30b7119e7e9741fd62a05b77bbd2b1d4fa2a7eb6b7a9190b0fda33ee9fc6d
-r--r--r-- 0/0           35123 1969-12-31 19:00 blobs/sha256/38fd192718a5d20f25ce8b7da3271929458a11823015da033eda4201527a5e42
-r--r--r-- 0/0          117912 1969-12-31 19:00 blobs/sha256/72c1c43b81af94397cdcc0e2246dcd4f3aa861c2155fd5e86a02071dfaabdf3e
-r--r--r-- 0/0           76907 1969-12-31 19:00 blobs/sha256/7f68ca843ac4d9c492771ab4750392eb0e4d0ef0118a4d07aaa6f74972ec79f6
-r--r--r-- 0/0            4897 1969-12-31 19:00 blobs/sha256/f84895033d4dc782528fbeb87bf710808174f61cf9a9b216c682f5371a1722c9
-rw-r--r-- 0/0             241 1969-12-31 19:00 index.json
-r--r--r-- 0/0              30 1969-12-31 19:00 oci-layout

Could someone explain what leads to such odd behavior? (e.g. could it be a bug that given a single .tar.gz it does not actually get zipp'ed but pretends in the content-disposition or smth like that? or is browser or webserver do some magic based on mimetype reflecting compression)

[rksharma-owg]

That download is a Buildx build record, not a Docker image export, so the contents you are seeing are expected.

The .dockerbuild artifact is an OCI-layout record containing build metadata, logs, stats, and blobs for inspection in Docker Desktop. It is distributed as an artifact by GitHub Actions, but it is not a ZIP file and it is not meant to be loaded with docker load. That is why tar -tzvf works while unzip reports a missing ZIP signature. The filename is a build-record convention, not a promise about the archive format.

If you want an image archive instead, configure an explicit build output, for example type=docker,dest=... for a Docker image archive or type=oci,dest=... for an OCI image layout. If you do not want the build record uploaded at all, the action documents DOCKER_BUILD_RECORD_UPLOAD=false for that.

[yarikoptic]

Thanks for chiming in @rksharma-owg !

The filename is a build-record convention, not a promise about the archive format.

I am not sure what convention you have in mind etc. My concern was that whatever (github, the action code, ...) is providing a download here, it should provide the content-disposition filename header (which is what is happening here I guess , artifact is no longer there given time passed) congruent with the content downloaded! And it is not (it gives me .zip for .tar.gz content).
I would be ok if the download had the .dockerbuild extension and was whatever that implies. My point was that somewhere along the path here, there seems to be some mismatch between extension and content.

[rksharma-owg]

Yeah, that’s a fair correction — I was too loose with “convention” in my earlier reply.

The .dockerbuild suffix identifies the Buildx build record, but it doesn’t explain away a .zip Content-Disposition when the response body is actually gzip/tar. Looking at the current action/toolkit path, the record is uploaded as the .dockerbuild file itself with archive wrapping disabled, so the intended artifact is not a ZIP wrapper.

If the GitHub download response is named .zip while file/`tar -tzf` can read the bytes as tar.gz, then yes, that’s a genuine filename/content mismatch somewhere in the artifact-download path. The fix should be either to preserve the .dockerbuild filename (with the actual record bytes) or to return a real ZIP if the filename says .zip. Your expectation is the right one. Sorry — my previous answer made it sound like the suffix alone settled the issue.