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

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

Что случилось

Бесплатный уровень GitLab для отдельных пользователей включает 5 ГБ хранилища, 10 ГБ передачи в месяц, 400 минут CI/CD и до 5 пользователей на пространство имён. Эти лимиты щедрые, но не бесконечные.

Когда появились сообщения о возможном удалении неактивных проектов, сообщество восприняло это как угрозу открытому коду и учебным проектам. Люди хранят на GitLab старые университетские работы, экспериментальные репозитории и архивы, которые не обновляются годами.

GitLab уже советовал пользователям самостоятельно удалять неиспользуемые проекты. Но удаление силами платформы — совсем другое дело: это ломает ссылки, CI и зависимые проекты.

# посмотреть размер своих репозиториев (если есть локальная копия)
du -sh .git
git count-objects -vH
# список удалённых репозиториев
git remote -v

Почему это важная тема

Бесплатные платформы для хостинга кода стали инфраструктурой. На них держатся документация, пакеты, примеры и учебные материалы. Удаление «неактивного» проекта может сломать сборку другого проекта, который от него зависит.

Кроме того, «неактивный» не значит «ненужный». Репозиторий может быть стабильным и не требовать коммитов. Архив курса, книга, конфигурация — всё это может годами не меняться.

# проверить, какие проекты зависят от вашего пакета (пример для Python)
pip index versions your-package 2>/dev/null
# для Node.js
npm view your-package dependencies 2>/dev/null

Что делать пользователю

  1. Держите локальную копию каждого важного репозитория.
  2. Настройте зеркала на другом хостинге.
  3. Экспортируйте архивы проектов, которые не планируете обновлять.
  4. Проверьте, какие ссылки ведут на ваши репозитории.
  5. Документируйте зависимости и способы сборки.
# зеркало репозитория на другой хостинг
git clone --mirror https://gitlab.com/user/project.git
cd project.git
git remote add backup https://github.com/user/project.git
git push --mirror backup
# архив
git archive --format=tar.gz -o project.tar.gz HEAD

Не полагайтесь на один хостинг. Даже платные платформы меняют условия, а бесплатные — тем более.

Лимиты и их влияние

5 ГБ хранилища хватает большинству небольших проектов, но большие репозитории с бинарными файлами быстро упираются в лимит. История Git хранит все версии, поэтому старые большие файлы занимают место даже после удаления.

Для очистки истории используйте git filter-repo или BFG, но будьте осторожны: это переписывает историю и требует force-push. Согласуйте с командой.

# найти большие файлы в истории
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '$1=="blob" {print $3, $4}' | sort -n | tail -20

CI-минуты тоже ограничены. Оптимизируйте пайплайны: кэшируйте зависимости, запускайте только нужные job, не собирайте всё на каждый коммит.

# пример кэша в .gitlab-ci.yml
# cache:
#   key: "$CI_COMMIT_REF_SLUG"
#   paths:
#     - node_modules/

Альтернативы

Помимо GitLab, есть GitHub, Codeberg, SourceHut и self-hosted решения. Для небольших команд self-hosted GitLab или Gitea даёт контроль, но требует обслуживания и резервных копий.

# пример запуска Gitea в контейнере (для теста)
docker run -d --name gitea -p 3000:3000 -p 222:22 \
  -v gitea-data:/data gitea/gitea:latest

Self-hosted — не «бесплатно»: вы платите временем, электричеством и риском потери данных. Зато никто не удалит ваш проект по решению платформы.

Что в итоге решил GitLab

После критики GitLab заявила, что не будет удалять неактивные проекты. Это победа сообщества, но она показывает, насколько важно следить за условиями сервисов.

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

# список ваших проектов через API (пример)
curl -s --header "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects?membership=true&per_page=100" | head -c 2000

Как экспортировать проект целиком

GitLab позволяет скачать архив репозитория, но он не включает историю и CI-переменные. Для полной копии используйте git clone --mirror и отдельно сохраните настройки, секреты и артефакты.

# зеркало с историей
git clone --mirror https://gitlab.com/user/project.git project.git
# архив рабочего дерева
git clone https://gitlab.com/user/project.git project
cd project && git archive --format=zip -o ../project.zip HEAD
# сохранить CI-переменные (пример через API)
curl -s --header "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects/$ID/variables" > variables.json

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

Безопасность токенов и доступов

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

# проверить, не попал ли токен в историю
git log -p | grep -iE "PRIVATE-TOKEN|glpat-" | head
# искать в файлах
grep -rIl "glpat-" . 2>/dev/null | head

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

Итог

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

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте