The current version of the Go base image that we use for our integration tests contains v2.28 of glibc. When building our integration test image we copy over the binaries built on the host to the image. If the glibc version used on the host to build our binaries is > 2.28, our integration tests may break because of incompatible glibc versions.
Steps to reproduce the bug
No response
Describe the results you expected
Integration tests should not break because of incompatible glibc versions and should be consistent across different operating systems.
We should either completely switch to building static binaries by default or (preferred) have the integration target build static binaries only.
Host information
OS:
Snapshotter Version:
Containerd Version:
Any additional context or information about the bug
I think this needs some thought on the tradeoffs between statically linking the snapshotter outside of the test container vs dynamically linking inside the test container.
Description
The current version of the Go base image that we use for our integration tests contains v2.28 of glibc. When building our integration test image we copy over the binaries built on the host to the image. If the glibc version used on the host to build our binaries is > 2.28, our integration tests may break because of incompatible glibc versions.
Steps to reproduce the bug
No response
Describe the results you expected
Integration tests should not break because of incompatible glibc versions and should be consistent across different operating systems.
We should either completely switch to building static binaries by default or (preferred) have the integration target build static binaries only.
Host information
Any additional context or information about the bug
No response