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  

[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.

[nsmithtt]

5 years later, still an issue. Couldn't the fix just be to tar before zipping automatically or just enable an option to use tar.gz instead of zip?

[rcdailey]

Here is my workaround: https://gist.github.com/rcdailey/cd3437bb2c63647126aa5740824b2a4f

Basically involves three files, and two custom actions:

.github/
└── .actions/
    ├── .download-tar/
    │   ├── action.yml
    │   └── untar.sh
    └── .upload-tar/
        └── action.yml

Examples of how they're used in my workflow jobs:

- name: Upload Artifacts
  uses: ./.github/actions/upload-tar
  with:
    name: ${{ matrix.runtime }}
    path: publish

- name: Download Artifacts
  uses: ./.github/actions/download-tar
  with:
    name: ${{ matrix.runtime }}
    path: publish

They're very simplistic (mainly because this is all I need for my particular project) but I'm happy with them and they do their job. Hopefully these custom actions will help others.