switch back to debian11 docker image which uses python3.9.

The newer image with debian12 uses python3.11 and that breaks when loading the ciwebsitebuilder package

Thanks for investigating the cause of the issue! Is there a ticket for Debian 12 and the the ciwebsitebuilder package?

I don't know how this could be fixed - as I just wrote in an email, the issue is caused by some python package 'lya' (which I can't really find anything about) which is imported from a private repo of Steffen's https://gitlab.dune-project.org/smuething/grabbox

The problem is that this lya package needs upgrading to work with Python3.11 but we can't do that. So switching to Python3.9 seems the only thing we can do at least for a short term fix.

What is this grabox/logbook about? We should not build on private non-maintained python packages if possible - otherwise we have no chance to do any update.

Finally figured out what package lya is https://github.com/mk-fg/layered-yaml-attrdict-config Project archived 2021. There are some links (from 2015) given on that page for replacement packages.

We switched to debian-12 because the debian-11 hugo package is outdated and does not build the website anymore.

One solution could be to provide python-3.9 or something similar, also in debian-12 and make this the default. There are so many issues with the python-3.11 version.

I added debian11 to the set of allowed images to the Gitlab Runner and now CI runs on that image... Ping me if you need to try other images, and when you are done so that I can restrict them again to only one.

Switching to debaian11 doesn't help because now hugo is the problem as @simon.praetorius already mentioned. Adding Python3.9 to the debian12 image could be a solution for now. Removing 'grabbox' or at least moving it into ci-website-builder and trying to fix the issue there would be important for long term maintainability. I can have a look at that in a few weeks.

I tried to add python3.9 to the websitebuilder image but failed - one possibly has to do that from source - does anyone know?

Probably, one has to build the python-3.9 from source, because it is not nativly shipped. But there is also an external repo one could add instead. I read that building python from source is also not so complicated. I can have a try.

Slightly independent of the issue discussed here:

Is there a way to have some automatic testing done during the upload of a new docker image so that such an issue as this here is caught before the upload is done? I couldn't find anything like that in the gitlab pages.

Perhaps something like this would work? https://docs.gitlab.com/ee/user/packages/container_registry/build_and_push_images.html

This was the issue we had when switching. I have uploaded a new image "debian12" first, then renamed the "latest" into "debian11", then added the new "latest" as "debian12". In this way at least I preserved the old image. This was, because the runner is limited to a few docker images only, and one cannot simply test another one. Maybe @santiago.ospina you could alow another docker image, e.g. [...]:debug, that can be overwritten just for testing new images, before replacing any other image.

@simon.praetorius Done

@andreas.dedner That procedure you point out needs you to have a docker-in-docker service available within the CI runner. This was not enabled because the runner was in conan and giving this service meant that someone could potentially escalate privileges to get into conan. Now, we moved it out to another computer and the container daemon uses podman instead of docker. The advantage is that because podman does not need root privileged to run and build containers, "docker-in-docker" (or podman-in-podman) is enabled by default. This means that it is now possible to build and push the image directly from this CI runner, but using podman instead of docker. If you are interested in trying this, let me know because I would need to allow the podman base image too.

closed