Automatic overwrite for the latest tag on push triggers, add basic test job

[Stevemoretz]

A better workflow:

Based on the conversation at: https://github.com/aaaamirabbas/nekoray-macos/pull/7#issuecomment-1512175031

Here's how I fixed it, if you push any commits, the check_tag step gets ignored, because you always want to build with the latest commit, but overwrite the previous faulty releases is now automatic.

The schedule (Running at 12 every night) is untouched which means that check_tag would still run and only build a new version if there is a new version available on the main repository.

Then I added a basic test step to it, what it does is as simple as running the build before release to make sure it runs, it doesn't do anything else just opens the built package and runs it and I defined it to run on 10.15, 11, 12 for amd and arm which means 6 tests will run, if the app runs for 10 seconds and doesn't crash or get an error the test will pass, you can change the test later and make it fit to your needs.

Here's an example of how the test job could fail: https://github.com/Stevemoretz/nekoray-macos/actions/runs/4732578884/jobs/8399290331

I'm running the MacOS app on Ubuntu (on purpose) to see how it fails, and it worked and failed.

Here's the working example that worked for all 6 varients of MacOS 10.15, 11, 12 for amd and arm, of course since your build target is 10.9 you might want to add 10.9, 10.10, .... as well, just look in the workflow file and find the matrix section and add more OSes if you want.

---

This is a good starting point for your repository's CI, I leave the rest to you, you can add cache functionality to make your builds faster, you can improve the tests to do something better than just opening and checking for crash or errors you can get the actual body of release from the original repository and add it so every version comes with some decent description or add a link to each original release and ...

The possibilities are endless.

[abbasnaqdi]

I thank you, this is great. Please return the changes you have made to nekoray_macos_builder.sh (unnecessary)

[Stevemoretz]

I thank you, this is great. Please return the changes you have made to nekoray_macos_builder.sh (unnecessary)

You're welcome, I forgot to mention what I did there, it fixes an annoying problem with your current script, at the end when you unzip the final zip files right now, like the one you built yesterday: https://github.com/aaaamirabbas/nekoray-macos/releases/download/2.25/nekoray_amd64.zip

You'll get a really long path that you need to go through to reach the .app file, the change you are talking about just removes that long path and after unzip you get the .app file only and not all those folders, I was experiencing that annoying problem and fixed it for you, if you insist on having that long path I'll revert it but I don't see why that would improve it.

[abbasnaqdi]

Using long routes makes the programmer not worried about which path is currently, this method helps develop and maintain scripts.

You haven't fixed the problem. You just used the cd instead of directly path.

The cd - code also causes the terminal to return to the home path (I don't want to happen) the terminal must return to wherever the origin was, so that the user can execute the script again if necessary.

You pay attention to GitHub Action, but it is important for me to handle the script themselves and have the best experience.

[Stevemoretz]

Using long routes makes the programmer not worried about which path is currently, this method helps develop and maintain scripts.

You haven't fixed the problem. You just used the cd instead of directly path.

The cd - code also causes the terminal to return to the home path (I don't want to happen) the terminal must return to wherever the origin was, so that the user can execute the script again if necessary.

You pay attention to GitHub Action, but it is important for me to handle the script themselves and have the best experience.

Thanks for explaining, I suspected cd - would be problematic, I pushed a few commits could you take a look now? I separated the long path, so locally you still get long paths which is easier for people to develop and no cd (even though I fixed the cd) but in github actions you get the short version so the people who download the release at the end would feel better about it, even for github I changed cd - to another method for actually getting back to the previous directory instead of going home, so they both be in the same place, so if you add anything later to the end of your script the result would stay the same for both CI and local environments.

So this should be fine now for both local, and CI (https://github.com/Stevemoretz/nekoray-macos/actions/runs/4735342556)