Зачем устанавливать GitLab?

Question

[Тарас Лабяк]

Зачем устанавливать GitLab на собственный сервер? Знаю это для параноиков, которые не хотят хранить где-то на стороне свой код. Если ли другие причины?

Comments

[Евгений]

Приватные репозитории гитхаба платные...

[Тарас Лабяк]

Евгений: gitlab, а не github

[Антон Уланов]

Тарас Лабяк: так гитлаб это по сути тот же гитхаб только свой

[Тарас Лабяк]

Антон Уланов: вы, вообще, о чем? О том что и то и то для людей, которые git используют? На bitbucket.com и на gitlab.com можно создавать бесплатные приватные репозитории. На gitlab.com в отличии от bitbucket.com количество участников репозитория неограничено и можно запустить свой сервер

[xotkot]

наверное проще ответить на вопрос, зачем лично вам нужен удалённый публичный/приватный репозиторий на неподконтрольном сервере.
Мне, например, с головой хватает Gogs работающего в локальной сети, а те проекты которыми хочу поделится выкладываю в свободный доступ на bitbucket или github

[Тарас Лабяк]

majetree: так зачем использовать свой сервер, если вероятность того, что он упадет на порядок выше чем неподконтрольний сервис, собственникам которого нафиг не нужно кому-то давать мои исходники. Да и вообщем если уж неподкотрольный сервис сдаст кому-то исходники, так почему же хостинг VPS на которому я установил свой сервер их не сдаст?

[xotkot]

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

собственникам которого нафиг не нужно кому-то давать мои исходники.

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

п.с.
да и плюс ко всему все эти скользкие лицензии не придают уверенности что всё не поменяется в один прекрасный момент.
Есть кстати интересный сервис на эту тему tosdr

[Тарас Лабяк]

majetree: за Gogs спасибо, посмотрю на досуге. Стоимость покупки, настройки, установки (или потраченого времени) серверов (в том числе для хостинга рабочего проекта) у себя в подвале должна быть оправдана. А надо еще учесть средства защиты от кражи с подвала (или другого помещения для серверов)

Answer 1

[Philipp]

GitLab устанавливают по следующим причинам:

1. Соблюдение коммерческой тайны
   
2. Изоляция от публичной сети (например развертывание в локальной сети учебного заведения)
   
3. Уменьшение финансового бремени (приватные репозитарии стоят денег)
   
4. Уменьшение зависимости от бизнес-модели. Например ГитХаб уважает законы других стран и реагирует на нарушения в правовом поле. ГитЛаб не несет отвественности, поскольку ответственность возглагается на того, кто его устанавливает и как им пользуется. Это значит, что вы можете захоститься где-нибудь в Корее и в репу насовать всякой дряни. ГитЛаб никак не может на это повлять, поскольку это невозможно.
   
5. Cреда непрерывной интеграции у Gitlab лучше.
   
6. Чтобы сказать Нет уродливому сине-фиолетовому цвету, который недавно на нем ввели.
   

Comments

[Тарас Лабяк]

3. Вопрос был о gitlab. Приватный репозиторий денег не стоит на gitlab.com ... Даже если бы и стоил, стоимость обслуживания собственого сервера значительно больше.
4. Я и основатели gitlab c Украины, так что юридические вопросы возникают общие... Да и я не знаю что же такое столь незаконное должно быть, чтобы компанию gitlab.com должны были объязать открыть доступ. Да и если будут, то это будет касатся не програмного кода, а данных
5. Допустим, для тех, кому это нужно

[Philipp]

3. Речь и шла о GitLab. Вы можете захостить его на своем личном компьютере в офисе и не тратить деньги на хостинг. Высунуть машину в интернет несложно.
4. Здесь речь идет не об открытии доступа, а скорее наоборот, об ограничении. Например кто-то украл код и разместил его в публичном доступе, или даже не код, а просто написал README.md и в нем описал, как сделать какую-нибудь петарду, способную убить человека. Это автоматически попадает под экстремизм или терроризм. А можно просто выложить туда гос.тайну по примеру ВикиЛикса. ГитХаб такое в момент прибьет. ГитЛаб на своем хостинге тоже. А вот непонятно где расположенный самозахостченный гитлаб будет жить. Даже если в стране его заблокируют, он все равно будет доступен из другой страны. Особенно, если хостинг абузоустойчивый.

Для нормального проекта с открытым исходным кодом проблем нет никаких. Вы можете спокойно хостить его на GitHub. И для закрытого кода тоже. Просто платите свой платеж и спите спокойно. В случае легитимного использования сервисов, хостить репозитарии у себя не имеет большого смысла. Но держать бэкап смысл имеет. А то вдруг метеорит упадет на датацентр.
Лично я пользуюсь GitHub и не вижу смысла с него съезжать куда-либо. Хотя их последние телодвижения не очень мне по душе.

[Тарас Лабяк]

Philipp: если я вдруг буду собирать свою секту терористов, то наверно я по возможности буду избегать публикации кода на бесплатных приватных репозиториях. Но если речь идет, допустим, о коде (вполне легальном) наебаловах, то врят-ли будут причины его раскрыть. Это если уже не говорить о коде, припустим, для сайта знакомств для педофилов. Вот почему я уточнил почему "для параноиков". Тем, кто захотят заполучить код наших проектов, будет проще взломать компьютер одного из разработчиков, не говоря уже об подкупить или украсть.
Захостить, это когда речь идет о том, что вы не считаете стоимость своего личного времени. И $7 в месяц/разработчик (пусть будем считать так) или обслуживающий админ - это вовсе ничто в сравнении с его оплатой труда.
Да, всегда можно опастатся того, что взломают gitlab.com и выложат код десятки тисяч репозиториев в публичный доступ

Answer 2

[vikarti]

Большой репозиторий + необходимость/желательность часто с нуля делать чекаут.
Мой случай - cocoapods в проекте и в соответствии с best practices - закоммичено, один из pod'ов - >900 Mb ( собранном проекте все нормально) + Jenkins (CI-сервер) который собирает и гоняет тесты по каждому коммиту + тормозящий в некоторых случаях интернет.
Пока решение - все же без переноса (уж больно много облачные решения фишек имеют, не переносимых локально) и git reset --hard в начале + НЕудаление workspace на Jenkins (да, понимаю, плохо и против рекомендаций).