cpp-linbuild currently treats Docker/Podman builder images as disposable: if an apparently-up-to-date image is available locally, we use it; if not, we build one. The builder image build process depends upon on a source for base images and the RPM package repositories of each of the supported Linux distributions for each supported major version (e.g. CentOS 7). That means that, in the absence of a previously-built builder image for a given platform, unavailability of the upstream, third-party infrastructure causes an unavailability of our ability to build packages for that platform.
This improvement would add image archiving via AWS ECR so that package building can proceed based on the availability of a previously-built image stored in ECR.
Key design considerations include:
Obsoleted images should be deleted after some amount of time or some number of successor images to limit AWS spend on ECR storage.
The build process should not grow a new, critical dependency on ECR. It must still be possible to build and use just-in-time images from available, third-party image and RPM repositories.
The ECR configuration needs to accommodate multiple instances (tenants?) so there can be at least a private/development instance for my use and a production instance for Scott’s use.
cpp-linbuildcurrently treats Docker/Podman builder images as disposable: if an apparently-up-to-date image is available locally, we use it; if not, we build one. The builder image build process depends upon on a source for base images and the RPM package repositories of each of the supported Linux distributions for each supported major version (e.g. CentOS 7). That means that, in the absence of a previously-built builder image for a given platform, unavailability of the upstream, third-party infrastructure causes an unavailability of our ability to build packages for that platform.This improvement would add image archiving via AWS ECR so that package building can proceed based on the availability of a previously-built image stored in ECR.
Key design considerations include:
Obsoleted images should be deleted after some amount of time or some number of successor images to limit AWS spend on ECR storage.
The build process should not grow a new, critical dependency on ECR. It must still be possible to build and use just-in-time images from available, third-party image and RPM repositories.
The ECR configuration needs to accommodate multiple instances (tenants?) so there can be at least a private/development instance for my use and a production instance for Scott’s use.