Adding CI workflow to build docker dev-env image

[ArturKlauser]

Added a CI/CD workflow that builds the development environment docker image (cwerg-dev-env). It is a multi-platform image for amd64 and arm64.

• It first builds the image for all platforms, pushing it onto a local ephemeral container registry.
• It then runs a test suite on the built image to make sure it is viable.
• Finally, if the tests pass, it publishes the image to the Github Container Registry (GHCR) for public access at ghcr.io/robertmuth/cwerg/dev-env

When images are built and published:

• From any commits to the main branch that touch the docker/* subdirectory, assuming that this constitutes changes to the development environment that need to be reflected in a new version of the image. All other changes to the git repository are ignored, i.e., changes to the Cwerg compiler don't trigger image builds. Such images are tagged latest and metadata labeled with the git SHA.
  • When the CI pipeline is triggered manually, it is handled similar to a commit to the main branch.
• Tag pushes to the git repository of the form devenv-vX.Y.Z also trigger image builds. Such images are tagged with the version number vX.Y.Z (and vX.Y, vX) and also metadata labeled the same.

Repushing images with the same tag (latest) results in the previously such tagged image to become untagged. A separate CI workflow garbage collects such images once a week (or if manually triggered).

The user quick start documentation has been updated.

[ArturKlauser]

Unfortunately, as far a I know, github doesn't allow you to run a new action workflow that isn't yet part of your main branch, not even for testing the PR that would introduce it. If you know otherwise, let me know, that would interest me.
Anyway, you can see a successful run from when I was experimenting with it on my fork or your repo: https://github.com/ArturKlauser/Cwerg/actions/runs/22528294561

[robertmuth]

Oh boy, I cannot believe all this bash/shell (?) scripting - is this what docker is built on?

Since I understand very little of this:
This is just "archiving" the docker image into the "cloud" with the extra twist that it support two architectures in on image right?

Concrete Suggestions:

There are two classes of tests in this file:

1. testing the (host) toolchains
2. testing the cwerg compiler

The first seems pretty useful in general.
Digression: In the past I had a lot of issues with qemu on the CI
because the package github pulled in was bad and I ended
up writing TestQemu/Makefile
I prefer running things via Makefile targets because that gives me a starting
point and an overview what is available ("leaving bread crumbs").
So my suggestion and I am even willing to do the work is to
rename TestQemu into HostValidationTest and do testing for python, c++ versions there similar to the qemu tests.
Some tests can probably stay within the Makefile other may call out into a script.
But such scripts would be selfcontained and not use libraries like "bats".

Inside docker you would just call cd HostValidationTest ; make validate

This may not be the docker way, so feel free to push back.
The upside is that it is a lot more likely that I will update those validation tests.
I would probably add them to the main CI suite.

For 2) would I similarly suggest adding a test target "sanity-test" to the top level
Makefile and then just call "make sanity-tests" from docker.
Same rationale: say we rename cwerg.py to cwerg. The top level Makefile is more likely to be updated than some somewhat obscure script in the docker dir.

[robertmuth]

I made some changes to TestHostSetup/Makefile along the lines of what I wrote for 1) above.
Habe a look - maybe it can be used to reduce the amount of scripting.