Артефакты и LFS в GitLab: как найти источник роста хранения

Исходный код меняется мало, а используемое хранилище GitLab растёт. Причину нужно искать по категориям ресурсов, а не только по размеру репозитория на экране.

Откройте детализацию пространства

Проверьте, какие объекты учитываются в действующей квоте: репозитории, LFS, результаты сборок и другие категории. Условия зависят от продукта и конфигурации, поэтому список нужно сверять с официальной документацией.

Найдите крупные и старые объекты. Перед очисткой проверьте, использует ли их действующий релиз или pipeline. Удаление нужного артефакта может нарушить рабочий процесс.

• Сравните расход по проектам.
• Отметьте большие бинарные файлы.
• Проверьте сроки хранения результатов сборок.
• Запишите порядок сохранения обязательных релизов.

Например, сборка сохраняет полный архив на каждый тестовый commit. Если эти результаты не нужны после проверки, политика хранения должна отражать это осознанно.

Новый ресурс после разбора

Если подтверждённый объём превышает доступный, согласуйте GitLab через NukaPay. Не выбирайте пакет по одной категории, забыв остальные.

Проверка закончена, когда рост объяснён конкретными объектами и будущая потребность рассчитана по ним.

Рабочий пример: от симптома к проверке

В GitLab репозиторий небольшой, а хранилище namespace растёт. В проекте есть LFS-файлы и артефакты сборок, которые нужно рассмотреть отдельно. Это условный рабочий пример, а не история клиента и не обещание результата сервиса.

В этом случае нужны следующие исходные данные: git-репозиторий, LFS, artifacts, registry и отчёт хранения namespace. Их лучше записать до изменения настроек. Иначе после нескольких попыток будет сложно понять, какое действие повлияло на результат и к какой версии относится наблюдение.

Контрольная проверка: разбор крупнейших категорий в отчёте до удаления или покупки дополнительного места. Сохраните исходное состояние, выполните проверку и сопоставьте результат с ним. Тест должен воспроизводить рабочую задачу, а не только подтверждать вход в сервис.

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

Ошибка, которая приводит к лишней покупке

Размер локального клона считают полным объёмом всех данных GitLab. Такой результат требует диагностики до следующей покупки: новый ресурс сам по себе не подтверждает исправление причины.

Хранилище анализируйте по категориям, которые показывает текущий отчёт GitLab. Крупные artifacts, LFS или registry требуют разных правил очистки. Не удаляйте объекты вслепую по размеру: сначала определите зависимости релизов и команд. После очистки проверьте фактическое изменение показателя и корректность нужной сборки.

Как сформулировать заявку в NukaPay

Предмет заявки здесь: продукт GitLab с ресурсом хранения по подтверждённым категориям использования. Перед оплатой найдите сервис в каталоге NukaPay и сопоставьте доступное предложение со своей задачей. Если название варианта не даёт однозначного ответа, уточните его состав, вместо того чтобы выбирать по одному совпадению бренда.

В заявке разделите три вопроса: что именно приобретается, к какому аккаунту или рабочей области относится покупка и какой период либо объём требуется. Для этого примера приложите несекретные сведения по пунктам: git-репозиторий, LFS, artifacts, registry и отчёт хранения namespace. Полную стоимость и условия конкретного заказа проверяют до оплаты; чужой старый чек не подтверждает сегодняшнее предложение.

Пароль, код 2FA и доступ к почте NukaPay не запрашивает.

Что проверить после выполнения заказа

Зафиксируйте результат приёмки по своему сценарию: источник роста найден, очистка не удаляет нужные версии и результаты сборок. Если он не получен, отдельно опишите состояние покупки и техническую ошибку. Сведения о заказе помогут проверить приобретённый продукт, а данные теста — продолжить настройку без повторения уже выполненных действий.

Перед передачей работы коллеге сохраните отдельно исходные условия и результат теста GitLab. Если использовался временный доступ, проверьте, кому он выдан и нужен ли после завершения задачи. Это особенно важно, когда заказ оформляет один человек, а принимает результат другой.

Источники

• Официальный источник 1