actions
download-artifact loses permissions on download
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.
Related to issue #9, however that issue only asks to document the flaw instead of fix it.
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.
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?
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
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).
