The a dedicated Docker based build per distro version is unsustainable. It took me about 6 hours to sort out several subtle broken behaviors in the Docker builds that use to work when prepping the latest release.
Currently it takes about 30 minutes to rebuild the full set of assets because of the number of Docker targets in play to try to support an increasing number of specific distro releases. This is prohibitively long if we want to start doing CI build tests on every commit or PR to catch broken behavior. And if we want to support arm, we're talking about doubling the build time to an hour unless we get this under control and reduce the number of docker builds being done or parallelize the process further.
The builds need to be refactored down to a base set that are tested to work at the distro family level. This should be accomplished by making sure libc (glibc or musl) component libraries are not included in the monitering-plugin assets, so that system provided libc implementation will be used as needed to fill run time library dependencies.
Or we find a way to statically compile these binaries.
This generally means using the oldest available distro family variant as the build target in multiple build definitions in the bonsai.yaml file and relying on linux host provided libc backwards compatibility symbols to work as designed.
Individual linux variants are added to the bonsai.yml as needed but reference the appropriate base build that works for the distro family.
If the included libraries are tuned correctly, there's no need to have separate Docker builds for each ubuntu,debian or centos releases, we can build 1 for each distro family at most and test that they work across the different versions.
The a dedicated Docker based build per distro version is unsustainable. It took me about 6 hours to sort out several subtle broken behaviors in the Docker builds that use to work when prepping the latest release.
Currently it takes about 30 minutes to rebuild the full set of assets because of the number of Docker targets in play to try to support an increasing number of specific distro releases. This is prohibitively long if we want to start doing CI build tests on every commit or PR to catch broken behavior. And if we want to support arm, we're talking about doubling the build time to an hour unless we get this under control and reduce the number of docker builds being done or parallelize the process further.
The builds need to be refactored down to a base set that are tested to work at the distro family level. This should be accomplished by making sure libc (glibc or musl) component libraries are not included in the monitering-plugin assets, so that system provided libc implementation will be used as needed to fill run time library dependencies.
Or we find a way to statically compile these binaries.
This generally means using the oldest available distro family variant as the build target in multiple build definitions in the bonsai.yaml file and relying on linux host provided libc backwards compatibility symbols to work as designed.
Individual linux variants are added to the bonsai.yml as needed but reference the appropriate base build that works for the distro family.
If the included libraries are tuned correctly, there's no need to have separate Docker builds for each ubuntu,debian or centos releases, we can build 1 for each distro family at most and test that they work across the different versions.