download-artifact loses permissions on download

[kcgen]

The baseline behavior of the zip utilty on Linux and macOS is to retain permissions.

However, when the download-artifact action zips a directory, it loses permissions. With permissions broken and lost in the resulting asset zipfile, this subsequently breaks the artifacts for users or for downstream automated scripts.

Yes, one option is to write a "github-download-permission-fixer" script that users must run after extracting the assets. However, this could be a lot of work to write and maintain, and hard to justify if it's simply to work-around broken behavior by GitHub. Likewise, if you're dealing with multiple platforms (Windows, macOS, Linux), this script will need to be cross-platform and conform to the lowest-common-denominator available on all platforms (such as bash 3.x on macOS). The alternative is to ask users to install prerequisites (such as bash 4.x) before they can run the github-permission-fixer script.

Expected behavior: permissions, as defined and applied by prior steps in the workflow to the resulting asset files and directories, should not be dropped or ignored by the download-artifact zipper, and should be present in the resulting asset zip file.

[kcgen]

Related to issue #9, however that issue only asks to document the flaw instead of fix it.

[reitzig]

Is there a big reason against using tar(.gz) instead?

[aibaars]

Is there a big reason against using tar(.gz) instead?

While I don't object to tar(.gz) there is no reason to switch archive format. The zip format is perfectly capable of preserving permission flags.

[Joknaa]

Is there any solution to this ?

[jozefizso]

Is there a big reason against using tar(.gz) instead?

While I don't object to tar(.gz) there is no reason to switch archive format. The zip format is perfectly capable of preserving permission flags.

How?

[fpoli]

download-artifact uses the @actions/artifact package, which in turn uses the unzip-stream package. The loss of permissions seems to be due to unzip-stream, which does not preserve them at the moment: https://github.com/mhr3/unzip-stream/issues/18

[rmunn]

https://github.com/mhr3/unzip-stream/issues/36 is a more recent unzip-stream issue, which suggests a solution: after the files have been extracted, run chmod (if on a Unix system) to set the file attributes correctly. (Unfortunately, they are stored in the "central directory" section of the .zip file, which is at the end of the file, so in a streaming environment you either have to hold off on extracting files until you've received the complete .zip, or else extract the files with incorrect permissions at first and then fix them later once the end-of-zip data has arrived).

[markfickett]

For now I'm just taring my directory before sending it to actions/artifact, which seems a little silly but gets around this issue of executable permissions, and not including dot-files by default (https://github.com/actions/upload-artifact/issues/447), and omitting some relative symlinks (https://github.com/actions/upload-artifact/issues/590).

jobs:
  make-my-artifact:
    steps:
      - name: Run npm build
        run: |
          cd frontend/
          npm i
          npm run build
          cd ..
          tar cfz frontend.tar.gz frontend/
      - uses: actions/upload-artifact@v4
        with:
          name: frontend-built
          path: frontend.tar.gz
          retention-days: 3

  use-my-artifact:
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: frontend-built
      - run: |
          tar xfz frontend.tar.gz
          cd frontend/
          npm run test