Due to the tags being not pinned enough, over time, the image that is used to build the natives is using a too new version of GLIBC.
In general the condition is that the GLIBC Version that the .net runtime layer provides has to be >= the version of the vcpkg part.
Ideally, the vcpkg commit id from the github action corresponds to the tag being used, but it doesn't seem like https://hub.docker.com/r/kuyoh/vcpkg provides that much of a variety, or we would have to downgrade the vcpkg in github actions. On the other hand, the github actions vcpkg is more meant for client builds and we do get feedback about build errors by the docker build anyway.
However, something to consider in the future in a follow up: This version conflict is only noticeable at runtime. I don't know how to best check that a docker image is running for "x seconds" and then force killing it though. Maybe we want special integration tests at some maturity stage.
Due to the tags being not pinned enough, over time, the image that is used to build the natives is using a too new version of GLIBC.
In general the condition is that the GLIBC Version that the .net runtime layer provides has to be >= the version of the vcpkg part.
Ideally, the vcpkg commit id from the github action corresponds to the tag being used, but it doesn't seem like https://hub.docker.com/r/kuyoh/vcpkg provides that much of a variety, or we would have to downgrade the vcpkg in github actions. On the other hand, the github actions vcpkg is more meant for client builds and we do get feedback about build errors by the docker build anyway.
However, something to consider in the future in a follow up: This version conflict is only noticeable at runtime. I don't know how to best check that a docker image is running for "x seconds" and then force killing it though. Maybe we want special integration tests at some maturity stage.