Chcę, na moim własnym serwerze, udostępnić prywatny Git hosting dla rodziny i przyjaciół. Dostęp z założenia ma być do tego półprywatny — zapraszam ludzi którym ufam, ale oni mogą zapraszać do współpracy nad swoimi projektami następnych bez mojej wiedzy (przynajmniej dopóki nie zacznie to być kłopotliwe). Na szczęście Internet twierdzi, że istnieje kilka projektów dających mi takie możliwości. Przetestowałem więc kilka pierwszych sugestii i prezentuję wnioski.

Założenia

Projekty jakich się tu spodziewam to pomniejsza hobbystyczna dłubanina, ale sam z przyczyn kontraktualnych nie mogę do czegoś takiego używać Githuba. Repozytoria powinny być dostępne po zarówno po SSH jak i HTTPS, ale nie chce rozdawać pełnoprawnych kont shellowych, najlepiej więc mieć osobny kontener. Nie mam zamiaru poświęcać temu zbyt wiele czasu, więc najlepszym rozwiązaniem jest Docker.

Końcówkę HTTPS mam w Nginx, konfigurowaną jak w http://blog.lrem.net/2018/11/27/nginx_proxy/, więc nie muszę się przejmować certyfikatami w kontenerze.

Aby porównać zachowanie różnych systemów na czymś nietrywialnym, za przykładowy projekt średniej wielkości biorę nieoficjalny mirror SQLite: https://github.com/myackyle/sqlite (19.8k commitów w 18 lat, 198MB na dysku). Podświetlanie kodu w różnych językach oglądam sobie na przykładzie https://github.com/lrem/ladders (Python, Shell, Typescript, …).

Gitlab Community Edition

Instalacja

Gitlab CE to smok ze sporym drzewkiem zależności, dlatego Docker jest chyba najpopularniejszą metodą instalacji. Dokumentacja jest na wysokim poziomie, zaś kiedy udało mi się zepsuć konfigurację, Google znalazło mi wątek gdzie wytłumaczono użytkownikowi jak naprawić dokładnie mój błąd (który był już wytłumaczony w rzeczonej dokumentacji, uch).

Administracja

Pierwsze uruchomienie Gitlaba tworzy przeogromny plik konfiguracyjny. Spora część jego zawartości odnosi się do funkcji dostępnych tylko w wersji komercyjnej, większość tego co dostępne i tak najlepiej zostawić w spokoju. Główne zastosowanie tego pliku to ustawianie portów i URL-i.

Przy pierwszym użyciu interfejs wiedzie nas przez utworzenie konta root. Konto to ma dostęp do panelu w którym możemy zmieniać różne aspekty zachowania repozytoriów, kont, organizacji, systemów CI/CD, wyglądu interfejsu i tak dalej. Monitorowanie jest domyślnie skonfigurowane z użyciem Prometheusa w kontenerze.

Używanie

Interfejs jest momentami łudząco podobny do Githuba. Ma nawet nowe funkcje, szczególnie spodobało mi się rozróżnienie na private projects i contributed projects. Import ma dziesięć osobnych integracji. Integracja z Githubem bierze access token, po czym pozwala skopiować wybrane repozytoria lub pełną zawartość konta. Kopiowane są też Wiki i Issues, ale z tego co rozumiem tylko przy początkowym imporcie. Możliwe jest ustawienie, żeby zmiany w kodzie na Githubie były aplikowane do Gitlaba, ale w drugą stronę jest to usługa płatna.

Import SQLite, jako projektu nie na moim koncie GH, możliwy jest tylko jako Repo by URL. Jest to git clone i polling ze strony interfejsu. Po lekko ponad pięciu minutach ukazało się moim oczom repozytorium.

Gitlab wydaje się mieć wszystkie funkcje, których bym oczekiwał. Podświetlenia kodu są w niektórych przypadkach lepsze niż w GH. Poza typowym edytorem ma troszkę bardziej rozbudowane Web IDE. Denerwuje ciągłym “CI/CD pipeline stuck” w domyślnej konfiguracji, gdzie nie mam zdefiniowanego CI/CD. Ale wyłączenie tego to tylko parę zbędnych kliknięć. Za to może się przydać kiedyś przy jakimś poważniejszym dłubaniu.

Co jest poważnym problemem Gitlaba, to to że każde kliknięcie wiąże się z zauważalnym czekaniem. Intuicyjnie trudno nawet powiedzieć co się tam dzieje - wyświetlenie listy plików w repozytorium, które mieści się na dyskietce, nie powinno zajmować zauważalnie długo. Zerknięcie pod maskę nie pomaga: Gitlab, nawet w podstawowej konfiguracji, to chmara przeróżnych daemonów. W tej chwili w kontenerze widzę 143 procesy i, mimo że nic nie robię, pięć do dziesięciu procent zużycia procesora.

Gitea

Instalacja

Gitea z założenia jest prościutka w instalacji - rozprowadzana jest jako pojedyncza binarka. Oznacza to, że Docker jest dla autorów zmartwieniem drugorzędnym… Co widać po błędach w dokumentacji. Podaje ona listę zmiennych środowiskowych do konfiguracji, które z tego co widzę zostały zignorowane. Zamiast tego, po uruchomieniu strona pokazała konfigurator. W docker run wystarczy więc zamontować /data i wystawić porty 22 i 3000 (z jakiegoś powodu postanowili nie używać 80).

Administracja

Pierwszy użytkownik który się zarejestruje ma uprawnienia administratora. Panel jest znacznie mniejszy niż w Gitlabie, co niekoniecznie jest złe. Co jest śmieszne, to to że ustawień w nim widocznych nie da się zmieniać. Początkowy konfigurator tworzy plik app.ini, który można sobie otworzyć w Vimie. Monitorować można też Prometheusem, ale spoza kontenera.

Używanie

Interfejs znów intuicyjny po znajomości Githuba, ale mniej wszystkiego niż w Gitlabie. Nie ma rozdzielenia między własnymi a cudzymi projektami. Przy imporcie w interfejsie jest opcja mirror, z tego co rozumiem powoduje to automatyczne git pull (może też push?) co dziesięć minut. Import ostrzega, że nie potrafi wciągnąć obiektów LFS. Nie ma też możliwości ściągnięcia Issues ani Wiki. Jest to po prostu bezpośrednie git clone.

Import SQLite skończył się na 504 Gateway Time-out, po którym repozytorium istniało, ale rzucało 500 (z Gitei, nie proxy). Zaczęło działać po około 3 minutach 40 sekundach od początku procesu.

Gitea ma pewne braki w funkcjonalności. Przykładowo nie pokazuje w żaden sposób git blame. Czasami, z bliżej nie określonych powodów, nie oferuje mi wbudowanego edytora. Nie jest to prosty brak przycisku, próba przejścia bezpośrednio do URL edycji pliku we własnym repozytorium kończy się w takich momentach 404, choć czasami to samo da się edytować. Co mnie dość mocno zaskoczyło, admin może pchać kod do repozytoriów innych użytkowników bez pytania o zgodę, co mi się zdarzyło przez przypadek.

Plusem Gitei jest wydajność - wszystko pojawia się natychmiastowo. W kontenerze siedzi osiem procesów, używa trzydzieści razy mniej pamięci niż Gitlab i jak nic się nie dzieje to nie grzeje procesora.

Gogs

Gogs to projekt z którego wywodzi się Gitea. Po tym, że nadal rozwija się osobno, wnosiłem że może się istotnie różnić. Ale poza niuansami w CSS, to Gogs widocznie różni się tylko brakiem przypadkowych gadżetów. Zużywa też mniej pamięci, ale w obu przypadkach to ilości pomijalne… Choć, jeśli chcesz hostować na najstarszym Raspberry Pi, to może to być akurat w okolicach progu ;)

Gitbucket

Gitbucket nie jest OpenSource. Nie jest nawet darmowy, to tylko freemium. Dziękuję, postoję.

Wnioski

Na dzień dzisiejszy zostaję przy Gitei. Gdybym organizował firmę, albo chociaż poważniejszy projekt na boku, to pewnie wolałbym Gitlaba z jego dodatkowymi możliwościami. Jednak przy tym poziomie doraźnej dłubaniny szkoda na niego prądu. A tym bardziej gigabajtów RAM-u. Mam jednak nadzieję, że wyświetlanie git blame pojawi się w Gitei raczej wcześniej niż później.