build with GH actions and Docker

[mgmax]

(updated)

Add GitHub actions in parallel to the old buildserver.

Currently implemented:

• Trigger the old buildserver (unchanged) for every commit on master
• Run build pipeline on GH actions for every commit and PR
• Save output as build artifact (Note: artifacts are deleted after 90 days)

Not implemented:

• Permanent archive / release creation

[TheAssassin]

I am willing to help in polishing this. I have quite some experience with CI and especially GitHub actions.

Some thoughts:

Save output as build artifact (Note: artifacts are deleted after 90 days)

That's normal. It's also a regular build step. Binaries should be uploaded in a separate step in my opinion, especially when running multiple jobs in parallel (back in the times when GitHub actions did not exist and Travis CI was used by everyone, we ran into race conditions a lot due to the lack of an artifacts storage).

Beware that artifacts can be downloaded only when logged into GitHub for some reason.

Run build pipeline on GH actions for every push to master
Build other branches

Just delete the branch filter and the pipeline is going to be run on all branches automatically. You may need such a filter only for singular build steps if you want to implement some fancy auto releasing. But there are better solutions that do not require any such filtering (see below!).

For manual builds, there is the workflow_dispatch event which can accept parameters.

Build (without archiving) for pull requests

Why not test end-to-end? The builds shouldn't take that long anyway. You want to have CI changes be tested, too.

Permanent archive / release creation

Please see pyuploadtool, which automates uploading binaries to GitHub releases in an opinionated way (including features like filtering branches, i.e., uploading binaries only for releases, which means the tool can be run with every build, it will automatically skip uploads on feature branches).

You can see it in action for instance on AppImageUpdate's release page. There is a continuous release which is recreated for every new commit on main, and stable releases that are created automatically for tags.

I can implement this in my fork and send a PR to your branch.

[mgmax]

I'm happy to hear that you want to help and that you know more than me :-) I would personally prefer a solution with less external dependencies. On the other hand, I have to concede that GitHub does not offer a reasonable solution without external tools. For example, they stopped supporting their "create release action" and refer to third party forks instead. So I have nothing to propose that is better than yours. Is there maybe a variant of your solution where the dependency is fixed to a specific hash / commit ID? Looking forward to your PR, I will then just close this PR.

[mgmax]

I updated the PR content and description:

• Do not remove the old build server trigger, but keep it in parallel
• also build on PRs

I think the current result is a useful first step, so I would merge this sooner or later if there is no other feedback.

[TheAssassin]

Totally forgot about this. Looks good to me as a first step. I'd like to have it merged before sending my own PR. I'll take your feedback into account. Approved by me (if that matters to you).

[TheAssassin]

For the record, I just tagged a release on pyuploadtool. I still think master is a good target (obviously, I write that software and if it's broken we'd notice quickly enough) but occasional tags should help have some "known good" states. https://github.com/TheAssassin/pyuploadtool/releases/tag/20231223-1