Comments 10
"для пары репозиториев и команды из нескольких человек "...
Для такого сгодится папка на сетевой шаре.. я так клиентские приложения по локальной сети раскидываю. Никаких серверов не нужно вообще.
А вот если все-таки нужен реальный репозиторий, то аппетит приходит во время еды. У меня тоже был сначала gitea, а сейчас полноценный gitlab с runner-ами, которые Docker-образы собирают сами. Не знаю есть ли такое в gitea.
Gitea пошли с какого-то времени в коммерческом направлении. Есть их форк - Forgejo (на нём хостится, к примеру Codeberg).
Да, это верно подмечено. Тоже смотрю в последнее время в его сторону. Помимо лицензии forgejo больше углубляются в безопасность (часть проблем из статьи там были бы не актуальны).
Но опыта у меня с ним не много и писать текст не готов про него. Как-нибудь надо будет обязательно погрузиться. Надеюсь у них получится перетащить комьюнити к себе.
Момент с GitHub как запасным зеркалом. После git remote rename origin github он ведь зеркалом сам по себе не становится: обычный git push уходит только в Gitea, и через какое-то время GitHub начнёт отставать. Если резон в том, чтобы при падении vps с него реально можно было продолжить работу, логичнее сразу включить push mirror из Gitea в ГитХаб и потом отдельно проверить такой сценарий восстановления. Иначе в нужный момент "зеркало" может оказаться просто старой копией.
У меня два Gitea сервера (удобно, когда 2).
Масса организаций, 49 репозиториев, код выкатывается на разные среды раннерами.
Все репо private. А если чем и хочу поделиться, то делаю зеркало на github.
Использовал раньше gitlab.
Как сказано выше - для меня переусложнение.
В Gitea есть коммерческие фишки, но их можно реализовывать самому без серьезных напрягов.
А где сборки храните?
Тоже пользуюсь gitea, но мне на vps уже посадили майнера, буквально пару дней на версии 1.27.0, следите за cve и обновлениями. И регистрацию сторонних пользователей лучше отключить
Свой git без gitlab‑комбайна: настраиваем gitea, подключаем ci и проверяем полное восстановление