Repository: shssoichiro/oxipng (language: rust)

Issue:
`oxipng` binary in GitHub release is not executable
In version 9.0.0, the `oxipng` binary inside the Linux and macOS archives is not executable.

This is the content of the linux-musl archive for 9.0.0:

```
-rw-r--r-- runner/docker   21994 2023-10-10 21:29 oxipng-9.0.0-x86_64-unknown-linux-musl/CHANGELOG.md
-rw-r--r-- runner/docker    1079 2023-10-10 21:29 oxipng-9.0.0-x86_64-unknown-linux-musl/LICENSE
-rw-r--r-- runner/docker    7192 2023-10-10 21:29 oxipng-9.0.0-x86_64-unknown-linux-musl/MANUAL.txt
-rw-r--r-- runner/docker    9310 2023-10-10 21:29 oxipng-9.0.0-x86_64-unknown-linux-musl/README.md
-rw-r--r-- runner/docker 1820976 2023-10-10 21:29 oxipng-9.0.0-x86_64-unknown-linux-musl/oxipng
```

Compare with 8.0.0:

```
drwxr-xr-x runner/docker       0 2022-12-24 15:25 oxipng-8.0.0-x86_64-unknown-linux-musl/
-rw-r--r-- runner/docker    6001 2022-12-24 15:25 oxipng-8.0.0-x86_64-unknown-linux-musl/README.md
-rwxr-xr-x runner/docker 1653120 2022-12-24 15:25 oxipng-8.0.0-x86_64-unknown-linux-musl/oxipng
-rw-r--r-- runner/docker   20471 2022-12-24 15:25 oxipng-8.0.0-x86_64-unknown-linux-musl/CHANGELOG.md
-rw-r--r-- runner/docker    1079 2022-12-24 15:25 oxipng-8.0.0-x86_64-unknown-linux-musl/LICENSE
```


Discussion / hints:
Thanks for the report! The root cause of this problem is https://github.com/actions/upload-artifact/issues/38, which prevents executables from retaining their special permissions when stored as GitHub Actions workflow artifacts. This was not an issue in the previous release as the binaries were built and zipped during the release workflow, without storing the binaries as artifacts at all.

I think it's fair for the final release tarballs to have the execute permission bit set as before. Note that, due to the above problem and the apparent lack of plans for upstream maintainers to do anything about it, it can't be fixed for artifacts, that can be considered release "snapshots" of sorts, so there will be some inconsistency here. That inconsistency should not be a concern as those artifacts are for advanced users anyway and were introduced that way recently. (Technically, with `upload-artifact` being an open source project one could send a PR to fix that, but my experience submitting PRs for GitHub-owned repositories has been that they are blatantly ignored, so I'm not too keen on doing work that likely nobody in charge will review, and I don't think this is too important of an issue to warrant maintaining a custom fork.)

Fix patch:
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
index 8207ef60..a076f951 100644
--- a/.github/workflows/deploy.yml
+++ b/.github/workflows/deploy.yml
@@ -67,6 +67,12 @@ jobs:
             *)
               cp ../LICENSE "$ARCHIVE_NAME"
               cp oxipng "$ARCHIVE_NAME"
+              # Execute permissions are not stored in artifact files,
+              # so make the binary world-executable to meet user
+              # expectations set by preceding releases.
+              # Related issue:
+              # https://github.com/shssoichiro/oxipng/issues/575
+              chmod ugo+x "$ARCHIVE_NAME"/oxipng
               tar -vczf "${ARCHIVE_NAME}.tar.gz" "$ARCHIVE_NAME"/*;;
           esac
 


Test patch: