Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Artifact .zip is actually a .tar.gz#1410

Unanswered
yarikoptic asked this question inQ&A
Discussion options

Original issue where I reported was

What I observe is that havinghttps://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

image

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 bebids-standard~bids-validator~QREREU.dockerbuild.zip but after download I see that it is actually

❯ zip -l bids-standard\~bids-validator\~QREREU.dockerbuild.zipzip warning: missing end signature--probably not a zip file (did youzip warning: remember to use binary mode when you transferred it?)zip warning: (if you are trying toread 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.zipdrwxr-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)

You must be logged in to vote

Replies: 0 comments

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
1 participant
@yarikoptic

[8]ページ先頭

©2009-2025 Movatter.jp