Add automatic build on release

[ann0see]

@corrados This should automatically build Jamlus for Debian and macOS via GitHub actions. Once the windows installer is merged, it should also publish the Windows installer to GitHub releases.

This sets the latest tag in a slightly different way, but it should work (I will do a final check by pushing a release tag Done).

See this release: https://github.com/ann0see/jamulus/releases/tag/latest

The resulting files haven’t been tested yet and I‘m struggling with finding a way to automatically get the content of the latest release of the ChangeLog file automatically.
Also the release seems to disappear once the latest tag is gone.

[ann0see]

macOS seems to work. Windows 64 Bit (at least from my fork) doesn't seem to work (error 0xc000007b) but Windows is not part of this PR.

[corrados]

I am curious, what are you trying to achieve? Do you want to automate the release process in a way that I only have to set the Git release tag and everything else is done automatically? That would be great :-)

I‘m struggling with finding a way to automatically get the content of the latest release of the ChangeLog

What about adding a marker in the ChangeLog like, e.g., this:

### 3.6.2 (2020-12-12)

So you could simply search for the "###"?

[corrados]

Or maybe use "##" [edit: ### should be just fine] and rename the ChangeLog to ChangeLog.md so that the lines are treated as headlines. What do you think?

[ann0see]

Do you want to automate the release process in a way that I only have to set the Git release tag and everything else is done automatically?

That's the end goal, yes.

Nevertheless, I had some thoughts on this (just hypothetical):

• There is a trust/security issue since we must then trust the GitHub runner. We don't know if it's somehow corrupted. If you compile it, we only have to trust you. Not sure if "reproducable builds" might solve this issue (I've only heared of this, but don't exactly know what it is).
• How do we get the releases to SourceForge (can you do it manually)? This would also allow you to test if the releases really work.

What about adding a marker in the ChangeLog like, e.g., this:

Yes that would make it much easier. If somehow possible, I would prefer some kind of marker at the end of this line too (##) or |. So an entry could look like that:

## 4.0.0git <-- Note [...] ##
- Change 1
- Change 2
- Change 3

## 4.0.0 (0000-00-00) ##
- Change 1
- Change 2
- Change 3

The easiest to parse would be something like xml or similar, but that's not really user-friendly.

[ann0see]

Tested the .deb files on Debian 10. Both work once you have jack installed. Should we add it as dependency?

The only remaining "problem" is Windows now. It might be due to a corrupted vs redist 64 bit.exe file. On my pc it seems to compile well, so I don't really get the problem for Windows. I hope once the runners are updated this issue is gone.

[corrados]

Both work once you have jack installed. Should we add it as dependency?

The server does not need it. But I have no problem making it a dependency.

I have just added the markers to the ChangeLog file.

[corrados]

BTW, is this pull request ready to be merged or do you want to do further changes?

[ann0see]

Great! You can merge this PR and later I can add the changelog detection.

[corrados]

Ok, thanks!