Фон
Компания, в которой я работаю, рассматривает возможность перехода на Azure Devops. Мы реализуем несколько пилотных проектов и заметили, что уже превысили порог бесплатного уровня хранения для пакетов, что нас удивило:
По крайней мере, наши собственные nugets обычно не такие уж большие (КБ, возможно, младшие МБ), поэтому совершенно неожиданно, что мы уже сталкиваемся с этим.
Что я сделал
Я выполнил ручную очистку старых версий nuget, которые мы создали, и это нормально, потому что мы все еще находимся в пилотном режиме. Я также вручную обновил корзину.
Я также сократил политику хранения:
Я предполагаю, что, возможно, это ничего не ловит, потому что мы все еще слишком активно используем наши пакеты.
В документации MS указано, что может пройти до 24 или даже 48 часов, прежде чем вы увидите снижение числа Used
. Однако это окно прошло, и теперь между ним еще и выходные.
Кажется, это имело 0 эффекта.
Раздражает также то, что в обзоре артефактов не упоминается размер пакета, поэтому я не знаю, какие из них занимают больше всего места.
Артефакты внешнего пакета
Я вижу множество внешних пакетов, на которые ссылается наш собственный канал:
По словам коллеги, это происходит (преднамеренно), потому что мы используем частный канал. Предполагается, что он не будет занимать места в нашей ленте, но я недостаточно хорошо знаю эту функцию, чтобы опровергнуть или подтвердить это.
Вопрос
В конечном итоге мы, вероятно, перейдем на платную модель, но, поскольку мы все еще пробуем что-то, мы хотим остаться на бесплатном уровне (если только мы действительно не используем его достаточно, чтобы это не имело никакого смысла).
Что я могу сделать, чтобы снова получить пакеты размером менее 2 ГиБ?
Обновление ответа
Проверка хранилища, как было предложено в ответе Bright Ran-MSFT, показала мне, что это другой проект той же организации, который занимает большую часть места.
Этот другой проект в основном связан с интерфейсом, поэтому я посоветовался со своим коллегой. Он исследовал это и сообщил, что выводы private feed
неверны. Посылки хранились и заряжались.
Он очистил свою сторону, что должно вернуть нас на уровень бесплатного пользования (в худшем случае, через несколько дней).
Есть статья на b;pg: Оптимизация хранения посылок (и затрат!): очистили ли вы корзину, поскольку она включена в счет?
Я видел этот блог, действительно видел.
Это может быть полезно: когда удаляются прогоны.
Вы можете перейти в «Настройки организации» > «Артефакты» > «Хранилище», чтобы проверить, какие каналы (включая organization-scoped
и project-scoped
) использовали какой объем хранилища.
На странице выше вы можете увидеть, какой канал использует большой объем памяти. Затем вы можете перейти в этот канал, чтобы удалить ненужные пакеты.
Что касается политик хранения, установленных в каждом фиде, я заметил, что вы установили:
Maximum number of versions per package
» до «5»Days to keep recently downloaded packages
» на «30
»Однако вам необходимо знать, что любые версии пакетов, загруженные в течение последних 30 дней, будут сохранены, даже если количество версий пакета превышает 5
. Например, если за последние 30 дней из канала было загружено 10
версий пакета, все 10
версии (а не только 5
версии) будут сохранены. Подробнее см. в разделе «Автоматическое удаление пакетов с помощью политик хранения».
Если последующие новые версии пакета содержат функции и исправления ошибок из предыдущих старых версий, рекомендуется обновить ваши проекты, чтобы всегда использовать последнюю версию, и сократить/прекратить использование старых версий, чтобы старые версии могут быть удалены политиками хранения, как и ожидалось.
Когда вы вручную удаляете версию пакета, она обычно перемещается в корзину и хранится в течение 30 дней, прежде чем будет окончательно удалена. Версии пакетов в корзине по-прежнему учитываются как часть использованного хранилища. Вы можете перейти в корзину, чтобы навсегда вручную удалить ненужные версии пакета.
Я видел это, но там не было никакой информации, я предполагал, что у меня нет на это прав. Но я попробовал еще раз и теперь вижу, что мой проект действительно занимает не так много, 294 МиБ. Это еще один проект той же организации (компании), который занимает 2,23 ГиБ, так что это суммируется (в обе стороны).
@kbd, если в одной организации есть какие-либо проекты, к которым у вас нет доступа, возможно, вы не сможете просмотреть и уменьшить объем хранилища, используемого этими проектами.
Это немного окольно, но я приму это как ответ, поскольку проверка хранилища привела меня к правильному выводу. Я обновил свой вопрос информацией, чтобы отразить это.
Это не имеет никакого отношения к тому, как вы создаете пакеты, поэтому удалите тег asp.net-core.