Feat/add container cd

[RobertRosca]

This PR adds a Dockerfile for DAMNIT and a CI workflow to build a container and push it to GHCR. Intended usecase is adding a new desktop shortcut to the Visa VMs which will start up DAMNIT via singularity.

A follow up PR could (should?) bundle a small example DB with the image which can be selected from the GUI at startup so that we can say "Click the DAMNIT button/copy-paste this docker or singularity command to see a demo of the GUI", since without that it's just the DAMNIT GUI with an empty table and nothing to see.

To try and keep the size of the container as small as possible it's a multi-stage Dockerfile where the build stage sets up the build environment and a venv in /app with the required python dependencies, then the final unnamed stage copies over the /app directory, installs runtime requirements, then installs DAMNIT into the venv.

The resulting image is still relatively huge (~1GB) but a bit smaller than it would otherwise be with build tools/layers included.

Options if size is an issue

• After an (unrelated) meeting w/ DESY-people about VISA/containerisation we decided that, if download speeds are too slow for the image, we can publish the container to the DESY GitLab Registry as well as GHCR. That way the downloads will be done over LAN and should be much faster than from GitHub's registry.
• Alternatively there are tools to make containers slimmer and only store the files required to run a given application, this is done by triggering all the functionality of an application (e.g. by running tests) and only retaining files which were opened during this period. An approach like this can hugely reduce container size, but can also introduce issues if all files are not found during the probing phase.

Starting the GUI from the container can be done with:

# docker, excluded mounts:
docker run --rm -it --net=host -e DISPLAY=:0 ghcr.io/european-xfel/damnit:$TAG

# singularity:
apptainer run docker://ghcr.io/european-xfel/damnit:$TAG

As for the actual tags, the workflow will build the image and push it to the container registry with different tags based on the workflow trigger:

event	tag
tag release	damnit:{x.y.z}, damnit:latest - 'latest' and version no.
pull request	damnit:pr-{N} - pull request number
merge/push to master	damnit:edge - 'edge' for most recent commit to master

Which covers the main use cases I think we'd have: using a tagged release, a current PR, and using current head.

Tested this with some local PRs to a fork of the repo here: RobertRosca#3

• On PR trigger image tag was ghcr.io/robertrosca/damnit:pr-3, created from the PR branch
• On PR merge ghcr.io/robertrosca/damnit:edge, created from master branch
• On creating tag ghcr.io/robertrosca/damnit:0.1.0 and latest, created from master branch

Few additional comments:

1. I can modify the CD/tag generation a bit so that you can get per-branch tags, which would let you run damnit:mid_4656 to start up a specific branch. Seems like this would fit the feature-branch development style better than the current approach.

   But the problem with this is that any push to any branch would trigger the build, and branch names may not be unique. So if you merge a branch and create a new one w/ the same name then the image would be modified

   I would rather leave it as is, then if you want a feature-branch image build you can make a PR and it'll tag the image with the pr number.

2. Image build happens in parallel to tests. Could be set to only trigger after tests pass, but it's not a big deal.

3. There was some other kinda important point that I forgot... will leave this here in case I remember

[RobertRosca]

Worked as expected and pushed an image with tag pr-142: https://github.com/European-XFEL/DAMNIT/pkgs/container/damnit

You can test it out with:

docker run --rm -it --net=host -e DISPLAY=:0 ghcr.io/european-xfel/damnit:pr-142

Which should open the GUI directly.

[JamesWrigley]

LGTM!