upload-artifact does not retain artifact permissions

[kcgen]

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

However, when the upload-artifact action zips a directory, it loses permissions, which subsequently breaks the artifacts for users and downstream tools.

Expected behavior: the permissions applied to assets in prior steps should be retained by the upload-artifact zipper, and should be present in the resulting asset zip file.

[kcgen]

Adding this issue to the download-artifact action, as that's where the zipping is currently performed in the v1 API. actions/download-artifact#14.
Will leave this open in both repos open until it's solved (however github wants to manage this in their backend for v2).

[nhooyr]

Can confirm that with unzip -Z on the resulting .zip, there are no executable permissions on files that should have executable perms.

[jrozner]

Is anything being done about this? It's been over 6 moths and this is the recommended way by GitHub to handle artifact upload

[adriangb]

This is still broken as of today, very annoying.

[bcardiff]

I am not proud of it, but actions/cache@v2 keeps the permissions. If the goal is to pass some artifacts between jobs the following is working for me so far.

      - name: Artifact (with permissions)
        uses: actions/cache@v2
        with:
          path: /path/to/store
          key: artifacts-${{ github.run_id }}-${{ github.run_number }}

[thetroy]

A workaround is documented in the readme

https://github.com/actions/upload-artifact#maintaining-file-permissions-and-case-sensitive-files

  - name: 'Tar files'
    run: tar -cvf my_files.tar /path/to/my/directory

  - name: 'Upload Artifact'
    uses: actions/upload-artifact@v2
    with:
      name: my-artifact
      path: my_files.tar  

[koliyo]

Wow, this is a pretty massive problem imo, and really frustrating to see that nothing has happened since 2019 😮‍💨

Wonder what the accumulated time spent to fix this locally for users of this action has been since then??

Please fix this 🙏

[pdmtt]

This issue still persists as for 2024. Just lost some time trying to figure out why a downloaded artifact's permissions weren't as I expected them to be.

[rizface]

I don't know whether this is a good way or not, whe i trying upload and download artifact which is a golang binary, i set permissions for the binary file on the job that needs execute it

chmod 777 <binary filename>

[Vacxe]

Use tar for zipping archive and upload it as artefact
Example: https://github.com/danger/kotlin/blob/master/.github/workflows/publish_release.yml#L60

[rmunn]

Looks like there's a PR that would fix half of this issue: actions/toolkit#1609. (Edit: Nope, see below). That would store file permissions in the .zip files created by upload-artifact; the next step after that would be to fix download-artifact to recreate those permissions, but that can't happen until the permissions actually exist in the .zip file.

But that PR has been sitting there for four months with no review from the GitHub Actions team yet. Hopefully someone from the GHA team will notice that PR and give it some attention soon.

UPDATE: Looks like that PR wouldn't work (the zip.append method wants a mode property, not stats) so I created actions/toolkit#1723 which is basically actions/toolkit#1609 but passing mode into zip.append.