| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
The initial implementation was far more complicated than necessary.
Strip out the complexities in favor of a simpler and more direct
approach.
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>
|
| |
|
|
|
|
|
|
|
|
| |
With multiple `containers` projects updating VM Image metadata,
it would be very difficult to discover which Cirrus-CI setup
was responsible. Add the GCE project name to the list
of metadata labels to update when this container runs. This
will give more context as to which images are currently in use.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
|
|
Once built, this container can be utilized by automation to help keep
track of VM images. All parameters are passed in via env. vars.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
