Open FedeDP opened 1 year ago
Considering that @alacuku will already port the builder images to correctly use a docker repository, in the end we would have: falcosecurity/docker-builder
docker repository, with tags like:
any_gcc4.9.1-latest
any_gcc4.9.1-master
any_gcc6.0.0-commithash
centos_gcc4.8.5-latest
We will still need to support specific images (ie: images that do not rely on he official gcc ones but instead use distro-specific one, like the driverkit-builder-centos-x86_64_gcc4.8.5
) because some drivers absolutely want their distro gcc to build.
Given that we will still support distro-specific images, i am not sure whether we want to retain the architecture field in the builder images regex name, as distro-specific images could be arch-specific.
Given that we will still support distro-specific images, i am not sure whether we want to retain the architecture field in the builder images regex name, as distro-specific images could be arch-specific.
How many distros need a distro-specific
image?
For now, we only had one case (the aforementioned centos one). But we cannot tell it in advance unfortunately. Only time will tell!
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Motivation
It would be much simpler for us to rely on the official gcc images: https://hub.docker.com/_/gcc.
Feature
Official gcc images are multi platform; support x86_64, arm64, arm32 and s390x. Moreover, they are official, therefore they won't suddenly disappear.
Using them, we could drop the
arch
from our builder images regex, as all our builder images would be multiarch. Moreover, we could cover any gcc version we want; finally, we would also have a single image for each gcc version (no more a single image that provides a list of gcc versions!)I'd wait for #258 and the PR by Aldo to port the Images listing code from
docker client
tofalcoctl
.WDYT @EXONER4TED @alacuku @Lowaiz @dwindsor ?