<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> It would be really helpful to allow kaniko layer caching in a separate image repository within the same image registry (eg image/repository/path/cache). When the --cache flag is set, kaniko appends `cache` to the end of the repository set as the --destination. For example, if the --destination is set as image/repository/path, then kaniko will attempt to cache layers in image/repository/path/cache. As it stands now, this setting results in a 401 unauthorized from gitlab. To get around this, you have to set the --cache-repo flag to be equal to the --destination (ie --destination=image/repository/path --cache-repo=image/repository/path). While this works, it's less than ideal when combined with automated repository cleanup. Depending on the image (and the number of layers in the image) the cached layers end up taking up most of the allowed space in the image repository, limiting the number of actual images available to only 1-3. The cached layers also behave differently with respect to automated repository cleanup than a normal image would. For example, you wouldn't necessarily want a labor intensive layer that is rarely changed to be deleted from the cache to make room for less labor intensive layers that are changed frequently. Whereas, this kind of approach would be perfectly reasonable for normal images where you don't really need to retain older versions of an image. <!-- Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->