Find image repository retention solution
- Dominant language
- TypeScript
- Stars
- 10
- Forks
- 0
- Avg merge
- 20h 8m
- Merged PRs (30d)
- 30
Description
Our images are built in GitHub and not in OpenShift, so OpenShift retention policies don't work. We'll need to find another solution to automate pruning old images.
**Purpose**
- Avoid using too much space in image repository
- Avoid the need for manual intervention
**Acceptance Criteria**
- [ ] Figure out an automated solution to keep image repository usage down
**Additional context**
- Removing images is done by simply removing all the tags pointing to that image
- Challenges
- The tags are all stored in the tools namespace, so it is impossible to know if an older tag is for dev, test, or prod environment.
- If we try to keep only the most recent n images, they'll likely all be dev images
- If we try to retain images by date, we may accidentally remove the current prod image, since prod is not deployed often
- The current image tag for an environment can be found by looking in the deployment configs.
- My most recent thoughts on how to do this would be to:
- Use an OpenShift cronjob
- Remove based on date
- Have an extra check for the currently deployed images for each environment and make sure to keep those
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the deployment configs to identify the current image tag for each environment, then examine how images and tags are stored in the tools namespace. Compare an OpenShift cronjob and date-based pruning approach that preserves every currently deployed image. Done means image repository usage is reduced automatically without removing the active dev, test, or prod images.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, github
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100