Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux version is not executable by default #52

Closed
MCOfficer opened this issue Nov 30, 2020 · 9 comments · Fixed by #55
Closed

Linux version is not executable by default #52

MCOfficer opened this issue Nov 30, 2020 · 9 comments · Fixed by #55

Comments

@MCOfficer
Copy link
Contributor

Describe the bug

When extracting the current release's self-contained version, the file OpenDirectoryDownloader does not have an executable bit set. (I assume this is the same with the non-self-contained version).

To Reproduce
Steps to reproduce the behavior:

  1. Download the current release to a linux machine
  2. Extract using 7z, others should also work
  3. Try to run ODD
❯ ./OpenDirectoryDownloader --version                          
zsh: permission denied: ./OpenDirectoryDownloader 

Expected behavior
The zip should retain unix permissions.

This is likely because the build runs on windows, which can't retain unix permissions due to its own filesystem:

runs-on: windows-latest

If you want, i can improve the workflow to run on all OSs in parallel, which should also get rid of this issue.

Desktop (please complete the following information):

  • OS: Ubuntu 18.04.5
  • Version: v1.9.1.0 self-contained, also happened with earlier versions.
@KoalaBear84
Copy link
Owner

KoalaBear84 commented Nov 30, 2020

Yes, tried to fix that on Saturday, but indeed didn't work. I guess I have to do move it into different jobs then and use artifacts on more places.. :)

15cdadc

@MCOfficer
Copy link
Contributor Author

Unless i'm mistaken one can also get rid of a lot of duplicate code by running it in a matrix. Shall I try it?

@KoalaBear84
Copy link
Owner

KoalaBear84 commented Nov 30, 2020

Correct. It was like that before, and at that time I didn't understand the artifacts thing completely to make it work.

There is one caveat, and that's the Linux x64 thing that will release a Docker Hub image that needs to still work.

It would be nice if you can get it to work.

@MCOfficer
Copy link
Contributor Author

Do you have a better word for "non-self-contained", because this is kinda confusing.
image

@KoalaBear84
Copy link
Owner

Normal? 😂

@MCOfficer
Copy link
Contributor Author

MCOfficer commented Dec 2, 2020

hm.
image

normal it is ¯\_(ツ)_/¯

@KoalaBear84
Copy link
Owner

KoalaBear84 commented Dec 2, 2020

You are really doing a good job, nice to see you can do if statements in yaml, didn't have time to check all that before.

Ahh, I see already, when the first build and release finishes, it will immediately send a release email with only some files which are already uploaded.

So it needs to be a separate build job, and you can upload them all as artifacts. It will also append the commit text for every build as it seems. Probably need the same matrix for both jobs to be able to dynamically download the artifacts back.

@MCOfficer
Copy link
Contributor Author

It's a bit of a hassle, but if that's an issue i can certainly do it. It's also a nice workaround for softprops/action-gh-release#57.

@KoalaBear84
Copy link
Owner

Yes indeed, it would fix both issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants