Setup continuous deployments (releases + ghcr.io docker image)

[orzechow]

Let's write some GitHub Actions to automatically

• run the unit tests (on every push)
  • Core library
  • Demo
• deploy releases (on every merge into main)
  • bump version
  • create and push git tag with new version
  • deploy tar as release asset
  • build & deploy docker image with latest tag to ghcr.io
    • Core library
    • Demo
    • Tutorial
  • update latest tags of docker images on ghcr.io

We should make sure to also

• cleanup and update the main Readme w.r.t. installation options

[orzechow]

@ll-nick FYI

[ll-nick]

And let's run the unit tests too

[ll-nick]

I just added a workflow for executing the unit tests, see #61

To make sure it actually fails if a test fails, I pushed a broken commit (but fixed it again after 😝 ), see the workflows.

So far, that only covers the unit tests of the core library. Testing the demo unit tests only makes sense after we merged them to main (same goes for the docker deployment which is also done for the core library already).

[ll-nick]

Oh and for the tar releases, we probably need some versioning system right? Or do we simply deploy a dev release using the main branch?

[orzechow]

Oh and for the tar releases, we probably need some versioning system right? Or do we simply deploy a dev release using the main branch?

I'll setup a semantic versioning for that and the docker images as well.

Let's continue working with a main and feature branches (gitflow is too much overhead for a small repo like this) and auto-deploy a release on every merge to main.

The version will be written to a version file, which our docker compose files will refer to.
We can use this version in GitHub Actions by reading it into $GITHUB_OUTPUT.

[orzechow]

Alright, so I thought about the versioning.
Auto-bumping e.g. the patch version with each merged PR would be easy. But we'd like to be able to bump major or minor versions as well in some smart manner.

Now, there's a ton of tools to ease semantic versioning, releases etc. (most overkill).
From full blown npm beasts like semantic-release (and its github action part) to smaller (but less maintained) GitHub Actions like github-tag and github-tag-bump

The latter is quite nice, it checks the commit log for bumping commands (#major, #minor, #patch) with patch as default, generates a new version string and creates a git tag.
The new tag string is also available as action output for following actions (like updating the version file, deploying etc.)
Possibly, we should use DRY_RUN in order to first update and commit the version file, before tagging.

[ll-nick]

That sounds good. I like the version bump on merge to main. Sounds like little overhead and I think anything more than that is probably going to be overkill for what we do here 👍

[ll-nick]

@orzechow Do we want to release docker images for the demo on ghcr as well?

[ll-nick]

Do we want to release docker images for the demo on ghcr as well?

Ah nevermind, I missed it in the todo list above. I'll add that to the workflow too.

[orzechow]

@orzechow Do we want to release docker images for the demo on ghcr as well?

Why not? 😁

Users would still need the compose file though for X11 settings etc. (or we provide a docker run command with all these settings)

[ll-nick]

I just added that workflow to #61

Users would still need the compose file though for X11 settings etc. (or we provide a docker run command with all these settings)

You're right but then we are basically better of with docker compose.

We could just change the service and remove the build: setting. The docker deploy workflow does not rely on this service so I guess that would be easiest.

And come to think of it, to keep things consistent, we could release the tutorial docker image too and also remove the build: setting.

[ll-nick]

Completed with #61 🎉

[orzechow]

@ll-nick FYI: our current approach with bumping the version after PR merge, can fail when merging multiple PRs in a short period (as I did with #91, #93, #94 and #95).
E.g. update-version-file of job 33586229265 failed, because main has changed between the jobs repo checkout and push.

It's a rare edge case, but doesn't feel great…

[ll-nick]

Yes, I'm aware of that. I purposefully merged stuff one at a time in the past but of course that's not the nicest solution. GitHub actually has a setting for that. We should look into that. At first glance, this seems like it would solve our problem.