Какие правила хранения образов удерживают реестр контейнеров компактным, не удаляя при этом ещё развёрнутые образы?

Открытый вопрос

Упомянутая документация Distribution объясняет, что слои хранятся один раз по адресу содержимого и разделяются между манифестами, что удаление манифеста через API убирает только ссылки, а последующая сборка мусора удаляет уже сами blob'ы, на которые не ссылается ни один манифест, — в ходе прохода mark-and-sweep, во время которого реестр должен быть доступен только для чтения. Управляемые реестры оборачивают это в правила жизненного цикла: упомянутое руководство по ECR описывает политики, которые помечают образы как устаревшие в порядке приоритета правил в течение примерно 24 часов после срабатывания условия, и рекомендует перед применением политики сначала посмотреть предварительно, какие образы она пометит как устаревшие.

Чего документация не говорит, так это какие правила безопасны для команды, которая собирает образ на каждый коммит, разворачивает по digest'у и иногда откатывается на недели назад:

• Устаревание по возрасту или количеству («удалять манифесты без тега старше N дней», «хранить последние N на репозиторий») в противоположность правилам, учитывающим развёртывание, — тем, которые сверяются с тем, на что реально ссылаются работающие нагрузки или записи о релизах.
• Как сборки для pull request'ов и веток отделяются от релизных сборок, чтобы первые могли быть короткоживущими, а правило при этом никогда не срабатывало на вторые.
• Меняют ли настройки неизменяемости тегов, подписанные образы или attestation'ы, прикреплённые как referrer'ы, то, что обязано сохранять правило жизненного цикла. Упомянутое руководство по ECR утверждает, что образ, на который ссылается manifest list, не может устареть раньше самого списка, а артефакты-referrer'ы автоматически устаревают вместе со своим subject-образом; ведут ли себя так же другие реестры — тоже часть вопроса.
• Что происходило, когда правило оказывалось неверным: пропадал ли образ, нужный для отката или расследования, и как его восстанавливали?
• К какому темпу роста правила удерживали реестр и что было исходной мотивирующей проблемой — стоимость хранения или задержка при pull'е.

Что содержит полезный ответ

Тип реестра и его механизм хранения; точные правила с порядком их применения; как релизные образы отличают от одноразовых сборок; как долго правила действуют без изменений; траектория объёма хранилища до и после; и хотя бы один инцидент или ситуация, близкая к инциденту, связанные с этим набором правил. Ответы, которые лишь пересказывают настройки вендора по умолчанию, должны это указывать; ответы от очень крупных парков серверов должны отмечать, какие их части зависят от инструментария, которого нет у небольшой команды.