Integracja z Git

Pozwól użytkownikom klonować, pobierać i wypychać projekty za pomocą Git przez git-bridge.

Integracja z Git jest obecnie dostępna w ayaka-notes/overleaf.

Ta funkcja została pierwotnie opracowana przez ayaka-notes/ayakaleaf-pro.

1. Włącz git-bridge (tylko dla użytkowników Toolkit)

   Jeśli używasz Toolkit, włącz git-bridge, ustawiając w pliku config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   Toolkit ignoruje to ustawienie, jeśli nie ustawiono również SERVER_PRO=true. Nic więcej nie jest potrzebne: Toolkit sam ustawia GIT_BRIDGE_HOST, GIT_BRIDGE_PORT i V1_HISTORY_URL dla kontenera sharelatex, więc pomiń dwa poniższe kroki dotyczące Docker Compose. Uruchom bin/up, aby odtworzyć kontenery.

2. Dodaj kontener git-bridge (tylko dla użytkowników Docker Compose)

   Jeśli używasz własnego pliku docker-compose.yml, dodaj do niego następującą konfigurację kontenera:

   docker-compose.yml (git-bridge service)

   git-bridge:
       restart: always
       image: ghcr.io/ayaka-notes/overleaf-pro/git-bridge:6.3.2 # tag should match the `sharelatex` container tag
       volumes:
           - ~/git_bridge_data:/data/git-bridge
       container_name: git-bridge
       expose:
           - "8000"
       environment:
           GIT_BRIDGE_API_BASE_URL: "http://sharelatex:3000/api/v0/" 
           GIT_BRIDGE_OAUTH2_SERVER: "http://sharelatex"
           GIT_BRIDGE_POSTBACK_BASE_URL: "http://git-bridge:8000"
           GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
       user: root
       command: ["/server-pro-start.sh"]
   

   Użyj tego samego tagu co obraz sharelatex. Serwer MCP (v6.3.1 i nowsze) jest częścią obrazu sharelatex i jest włączany razem z integracją z Git, więc nie wymaga dodatkowego kontenera.

3. Zaktualizuj konfigurację kontenera sharelatex

   Musisz również powiązać kontener git-bridge z kontenerem sharelatex i zdefiniować poniższe zmienne środowiskowe. Zwróć szczególną uwagę na V1_HISTORY_URL:

   docker-compose.yml (sharelatex service)

   sharelatex:
       links:
           - git-bridge
       environment:
            GIT_BRIDGE_ENABLED: true
            GIT_BRIDGE_HOST: "git-bridge"
            GIT_BRIDGE_PORT: "8000"
            # We use v1 now, if you used to set V1_HISTORY_URL, please update now
            V1_HISTORY_URL: "http://sharelatex:3100/api"
   
4. Uwierzytelnianie

   Do uwierzytelnienia klienta git użytkownicy potrzebują osobistego tokenu dostępu (Personal Access Token). Użytkownicy mogą zarządzać osobistymi tokenami dostępu w interfejsie aplikacji (zobacz dokumentację):

   

   Osobisty token dostępu dla integracji z Git

5. Monitorowanie i zasoby

   Po włączeniu git-bridge zalecamy monitorowanie zasobów hosta. Wzrost obciążenia będzie zależał od:

   • liczby użytkowników korzystających z tej funkcji
   • rodzajów projektów hostowanych w Twojej instancji (większe projekty zazwyczaj wymagają więcej zasobów)

​

Przenoszenie projektów do S3

Integracja z Git przechowuje na dysku kompletne repozytorium git dla każdego projektu sklonowanego przez użytkownika. Jeśli masz ograniczoną przestrzeń dyskową, możesz aktywować zadanie wymiany (swap), które przeniesie rzadziej używane repozytoria do AWS S3. Gdy przeniesione repozytorium będzie ponownie potrzebne, zostanie przywrócone na dysk. Zadanie wymiany kontrolują następujące zmienne środowiskowe:

Nazwa	Opis
GIT_BRIDGE_SWAPSTORE_TYPE	Ustaw na “s3”, aby aktywować zadanie wymiany.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Twój klucz dostępu AWS
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Twój sekret AWS
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Ten bucket będzie zawierał spakowane repozytoria git
GIT_BRIDGE_SWAPSTORE_AWS_REGION	Region bucketu
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Minimalna liczba projektów przechowywanych na dysku. - Domyślnie: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Dolny próg wymiany. Zadanie wymiany będzie przenosić projekty, dopóki zajętość dysku nie spadnie poniżej tej wartości. - Domyślnie: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Górny próg wymiany. Zadanie wymiany rozpocznie przenoszenie, gdy zajętość dysku osiągnie tę wartość. - Domyślnie: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	Odstęp czasu między sprawdzeniem zajętości dysku a uruchomieniem zadania wymiany. - Domyślnie: 3600000 ms = 1 godzina

​

Pytania i odpowiedzi

Jak działa model uprawnień Git Bridge, jeśli udostępnię projekt komuś innemu?

Użytkownicy z dostępem tylko do odczytu mogą jedynie klonować projekt; użytkownicy z dostępem do odczytu i zapisu mogą klonować projekty i wypychać do nich zmiany. Uwaga: aby dołączyć do projektu, użytkownicy muszą być zalogowani.

Jak sklonować projekt i jakiej nazwy użytkownika oraz hasła użyć?

W edytorze otwórz Integrations na lewym pasku i kliknij Git integration. Zostanie wyświetlone polecenie klonowania w postaci:

git clone https://<your-overleaf>/git/<project_id>

Gdy Git poprosi o dane uwierzytelniające, wpisz git jako nazwę użytkownika i Personal Access Token jako hasło. Wygeneruj token w Account Settings; jest ważny przez jeden rok. Hasło do konta nie zadziała.

Zmiany nie są synchronizowane automatycznie: użyj git pull, aby pobrać zmiany wprowadzone w edytorze, oraz git push, aby wysłać własne. Ścieżka /git jest obsługiwana przez kontener sharelatex, więc reverse proxy umieszczone przed nim nie wymaga dodatkowej reguły.

git push kończy się błędem HTTP 413 lub curl 55 Broken pipe

Wypychane dane przekraczają limit rozmiaru przesyłanych plików, ustawiany przez MAX_UPLOAD_SIZE (w megabajtach, domyślnie 50), który dotyczy również operacji push. Zwiększ go w config/variables.env, na przykład MAX_UPLOAD_SIZE=200, a następnie uruchom bin/up -d. Jeśli używasz proxy TLS lub własnego reverse proxy, zwiększ także jego client_max_body_size (50M w pliku config/nginx/nginx.conf w Toolkit).

git-bridge odrzuca również pliki większe niż 50 MB oraz projekty zawierające ponad 2000 plików. Limity te ustawiają zmienne GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (w bajtach) i GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM w config/variables.env.

Log git-bridge pokazuje Failed to fetch log level

To ostrzeżenie jest nieszkodliwe, a klonowanie, pobieranie i wypychanie nadal działają. W wersjach 6.2.x git-bridge raz na minutę pyta serwer metadanych Google Cloud (metadata.google.internal) o poziom logowania, co działa tylko w Google Cloud. W innych środowiskach żądanie kończy się niepowodzeniem, git-bridge zapisuje błąd w logu (np. null lub kod statusu HTTP) i zachowuje poziom z GIT_BRIDGE_LOG_LEVEL. Od wersji 6.3.0 to sprawdzanie jest wyłączone, a aktualizacja aktualizuje również obraz git-bridge, którego wersja odpowiada obrazowi głównemu.

Czy potrzebuję usługi track-changes lub OVERLEAF_IS_SERVER_PRO=true dla Git i pełnej historii projektu?

Odpowiedź: Nie. Ayakaleaf Pro nie ma usługi track-changes. Historię projektu przechowują usługi project-history i history-v1, które zawsze działają w kontenerze sharelatex. git-bridge odczytuje historię z history-v1 pod adresem V1_HISTORY_URL (http://sharelatex:3100/api), który ustawia Toolkit. Nie ustawiaj OVERLEAF_IS_SERVER_PRO: żadna funkcja od niej nie zależy, a jedynie przełącza migracje bazy danych uruchamiane przy starcie na zestaw Server Pro.