Add GitHub actions

[ll-nick]

See #59 for details.

This adds automated workflows to

• build and run unit tests of both the core library and the demo on any push to any branch
• on merge to main:
  • bump the version in the version file according to the version string in the commit messages (#major, #minor, #patch, #none). #minor by default.
  • create a new release and add debian packages as well as tar.gz and zip release
  • run the unit tests against the released packages
  • build and push new docker images for the core library, the demo and the tutorial

[ll-nick]

Changed the base to packaging_with_cpack since we need those changes for the release pipeline.

[ll-nick]

Alright @orzechow , this one is ready for review. It should be very analogous to the util_caching pipelines now. Feel free to push your release-test-pipeline onto this branch if we want to do that in one go.

[orzechow]

Alright @orzechow , this one is ready for review. It should be very analogous to the util_caching pipelines now. Feel free to push your release-test-pipeline onto this branch if we want to do that in one go.

Thanks!

One quick remark: the dockerfile is missing the release_builder stage etc.

Yeah, I'll add the release test pipeline after finishing the cpack PR

[ll-nick]

You're right. I think it's easier if one person just does it. I have moved the PR back to draft to wait until you finished the cpack PR.

I will then rebase this PR, add the Docker stage and release test pipeline and ping you once the PR is actually done.

[ll-nick]

Rebased on main

[ll-nick]

Ok @orzechow this one should truly be ready now.

See the edited PR description for all the things that are now going on the workflows.

I tested the workflow on a test branch where I didn't need a PR to trigger the workflow, see 82b31a0d2e551b35fb531e5b0fb21f45be565fc6. Other than that, the branch is identical to this one and the last run was succesful.

A couple of noteworthy changes I made since we last talked about this:

• Combine the release and the docker build workflows. This is due to the fact that we need the version bump to happen first. Otherwise the docker images will be tagged with the old version. Also I guess it's nice to wait for the release tests before publishing new images.
• The unit-test workflow now build the library core image before building the demo unit test stage. This is due to the fact that we want to test the state that the repo is in. Otherwise, the demo unit tests would run against the version that's currently hosted on ghcr (which doesn't even necessarily exist).

Before merging, I'll delete the tag, release and docker images created by the test branch. I will then merge this as a #minor release.