Add github actions to build containers

[hugopeixoto]

(This was based on @SISheogorath's branch)

There are two github action workflows:

• When someone makes a pull request, it runs the tests (test.yml)
• When a version tag (*.*.*) is created, the images are built and pushed to quay.io

To push to quay.io, you'll need to configure two secrets:

• DOCKER_USERNAME
• DOCKER_PASSWORD

For version 1.6.0, for example, this creates the tags:

• hedgedoc:latest
• hedgedoc:alpine
• hedgedoc:debian
• hedgedoc:1.6.0
• hedgedoc:1.6.0-alpine
• hedgedoc:1.6.0-debian

where the flavorless tags are based on debian (defined in main-flavor).

I had to change the tag calculating github action to support flavors, and am trying to upstream the changes: docker/metadata-action#15. For now this is pointing to my repository.

The release job is using buildx to support cross platform docker images, but for now this is limited to linux/amd64. If someone can test this on an armv7 for example we can expand this.

I changed some references from codimd to hedgedoc where I needed to, but I'm leaving most of that work to PR #119.

[hugopeixoto]

I updated the PR to remove .travis.yml, since it's no longer needed.

[SISheogorath]

Ehm, hint: We don't use tags on the container repository to be able to adjust system changes between releases when needed, as well as scheduling periodic rebuilds. Therefore triggering the build on tags is not necessary overly useful :X

[hugopeixoto]

We don't use tags on the container repository to be able to adjust system changes between releases when needed

Are you saying that you rather have this push images to the main branch of this repository, so that changes to this repository can trigger new images being published?

as well as scheduling periodic rebuilds

I didn't quite follow. Are you rebuilding periodically to account for updates to the base image? How is this periodic rebuild process currently done? github actions support scheduling jobs periodically, maybe we can use that as well.

I can replace the tag based execution with branch based execution, I'll just need to update the docker tags.

[SISheogorath]

Yes, we build it based on the main/master branch. And I think this is helpful to account for possible base image updates.

Until now we were using travis, which supported a sort of cron-service. We could consider letting renovate bot pin container images and use a full PR workflow instead using cron-based rebuilds. This would also safe the time for the figure out of GitHub actions supports something similar. (and it could and should be done outside of this PR :))

[hugopeixoto]

OK, I've updated it to deploy on branches main and master, if we ever decide to switch from master on this repo. The tagging code looks a big funkier now, since the action I was using was based on the git tag.

[SISheogorath]

I'll merge it tomorrow so everyone can have a look first :)

Thanks a lot for pushing the project forward.