| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
Rather than hard-coding all four base-image env. var name,
load the values based on the shared variable name suffix.
Thanks to Ed Santiago <santiago@redhat.com> for the suggestion.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
| |
|
|
|
|
|
| |
Also do some minor cleanup and add additional safety-checks to pruning
script (container image).
Signed-off-by: Chris Evich <cevich@redhat.com>
|
| |
|
|
|
|
| |
This reverts commit 9b2e98f1e872354f0708a86b59e16b8b86e9f8b2.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
|
|
Over time unless they're removed, the project could grow quite a large
collection of VM images. While generally cheap (less than a penny each,
per month), these will become a significant cost item if not kept
in-check.
Add a specialized container for handling image-pruning, but limit
it to only finding and printing (not actually deleting) images.
Also update the image-building workflow so that base-images used to
compose cache-images are also labeled with metadata.
N/B: As an additional safeguard, the service account which
executes the new container in production *DOES NOT*
have access to delete images. This can be enabled
by adding the GCE IAM role: CustomComputeImagePrune
Signed-off-by: Chris Evich <cevich@redhat.com>
|
