summaryrefslogtreecommitdiff
path: root/contrib/imgts
Commit message (Collapse)AuthorAge
* Cirrus: Reimplement release archive + uploadChris Evich2019-08-28
| | | | | | | | 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>
* Cirrus: Print images that should be prunedChris Evich2019-07-15
| | | | | | | | | | | | | | | | | | | | 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>
* Cirrus: Track VM Image calling GCE projectChris Evich2019-06-05
| | | | | | | | | | 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>
* [skip ci] Cirrus: Container for tracking image useChris Evich2019-01-24
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>