Chmod failed in unpacking

[gatk555]

First, let me thank you for this software, I have been using it a lot in testing, checking both CI builds and new features on Macs and Windows installations that I do not have locally. Until now, no problems.

The attached workflow file fails during the second unpacking:

==> Artifact name: ghdl-macos-13-x86_64-llvm
==> Local path: /usr/local
==> Workflow name: Pipeline.yml
==> Workflow conclusion: success
==> Run number: 468
==> Allow forks: false
==> (found) Run ID: 12794531184
==> (found) Run date: 2025-01-15T18:18:05Z
==> Artifact: 2436369918
==> Downloading: ghdl-macos-13-x86_64-llvm.zip (45.48 MB)
==> Extracting: ghdl-macos-13-x86_64-llvm.zip
inflating: /usr/local/pyTooling_upload_artifact.tar
Error: ENOENT: no such file or directory, chmod '/usr/local/pyTooling_upload_artifact.tar

The artifact file seems fine. If downloaded locally, it unzips without problem to a single tar file that also seems fine. It is likely significant that the file name has two leading and two trailing underscores (before ".tar") but this website mangles those.

Any advice will be appreciated.

Thanks, Giles

mac_ghdl.yml.txt

[dawidd6]

This website uses markdown for formatting 😄. You can surround your "code block" with "```" and it should be more readable.

I would need to have a better overview of this. Maybe you could setup some minimal reproducer repository?

[gatk555]

"This website uses markdown for formatting ...": this statement is not verifiable. In my experience, the "code block" works about one time in four. I did try it above, but today was not one of the good days. The site even mangles simple HTML in *.md files. I do not think I ever saw a reliable implementation of Markdown on a website, even if you only use the buttons. Perhaps it depends on the browser, but should not.

"Maybe you could setup some minimal reproducer repository?" The supplied file should be fine. It does contain a dependency on its home repository, but only after the failure point. But a maintainer's request for a minimal test case should never be refused, so the attachment contains only the failing step and no local dependencies. It fails the same way.

Thanks for looking, G.

demo.yml.txt

[gatk555]

Changing the invocation to use

    path: .
    skip_unpack: true

and calling unzip directly is a work-round.

[dawidd6]

I guess we could introduce a new boolean input like use_system_unzip or something, that will modify the Action behaviour to use unzip instead of AdmZip library. Might be useful for some.