Integrace s Gitem

Umožněte uživatelům klonovat, stahovat a odesílat jejich projekty pomocí Gitu přes git-bridge.

Integrace s Gitem je v současnosti k dispozici v ayaka-notes/overleaf.

Tuto funkci původně vyvinul ayaka-notes/ayakaleaf-pro.

1. Povolení git-bridge (pouze pro uživatele Toolkitu)

   Pokud používáte Toolkit, povolte git-bridge nastavením následující hodnoty v souboru config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   Toolkit ji ignoruje, pokud není nastaveno také SERVER_PRO=true. Nic dalšího není potřeba: Toolkit sám nastaví GIT_BRIDGE_HOST, GIT_BRIDGE_PORT a V1_HISTORY_URL pro kontejner sharelatex, takže dva níže uvedené kroky pro Docker Compose přeskočte. Spuštěním bin/up znovu vytvořte kontejnery.

2. Přidání kontejneru git-bridge (pouze pro uživatele Docker-compose)

   Uživatelé s vlastním souborem docker-compose.yml přidají do svého compose souboru následující konfiguraci kontejneru:

   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"]
   

   Použijte stejný tag jako u image sharelatex. MCP Server (v6.3.1 a novější) je součástí image sharelatex a povoluje se společně s integrací s Gitem, takže nepotřebuje žádný další kontejner.

3. Aktualizace konfigurace kontejneru sharelatex

   Dále je třeba propojit kontejner git-bridge s kontejnerem sharelatex a definovat následující proměnné prostředí. Věnujte pozornost proměnné 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. Ověřování

   Při ověřování git klienta potřebují uživatelé osobní přístupový token (Personal Access Token). Osobní přístupové tokeny mohou uživatelé spravovat v uživatelském rozhraní aplikace (viz dokumentace):

   

   Osobní přístupový token pro integraci s Gitem

5. Monitorování a nároky na prostředky

   Po povolení git-bridge doporučujeme sledovat prostředky hostitele. Nárůst zátěže bude záviset na:

   • počtu uživatelů, kteří funkci používají
   • typech projektů hostovaných ve vaší instanci (větší projekty jsou obecně náročnější na prostředky)

​

Odkládání projektů do S3

Integrace s Gitem ukládá na disk úplný git repozitář pro každý projekt, který si některý uživatel naklonuje. Pokud máte omezené místo na disku, můžete aktivovat odkládací úlohu (swap job), která přesune méně používané repozitáře do AWS S3. Pokud je odložený repozitář znovu potřeba, přesune se zpět na disk. Odkládací úlohu řídí následující proměnné prostředí:

Název	Popis
GIT_BRIDGE_SWAPSTORE_TYPE	Nastavením na “s3” aktivujete odkládací úlohu.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Váš přístupový klíč AWS
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Váš tajný klíč AWS
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Tento bucket bude obsahovat zazipované git repozitáře
GIT_BRIDGE_SWAPSTORE_AWS_REGION	Region bucketu
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Minimální počet projektů, které se mají ponechat na disku. - Výchozí: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Dolní mez pro odkládání. Odkládací úloha bude přesouvat projekty, dokud využití disku neklesne pod tuto hodnotu. - Výchozí: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Horní mez pro odkládání. Odkládací úloha začne odkládat, jakmile využití disku dosáhne této hodnoty. - Výchozí: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	Doba mezi kontrolami využití disku a spuštěním odkládací úlohy. - Výchozí: 3600000 ms = 1 hodina

​

Otázky a odpovědi

Pokud svůj projekt sdílím s někým dalším, jak funguje model oprávnění Git Bridge?

Uživatelé s přístupem pouze pro čtení mohou projekt pouze klonovat; uživatelé s přístupem pro čtení i zápis mohou projekty klonovat i do nich pushovat. Poznámka: Aby se uživatelé mohli k projektu připojit, musí být přihlášeni.

Jak naklonuji projekt a jaké uživatelské jméno a heslo mám použít?

V editoru otevřete v levém panelu Integrations a klikněte na Git integration. Zobrazí se příkaz pro klonování ve tvaru:

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

Když vás Git požádá o přihlašovací údaje, zadejte jako uživatelské jméno git a jako heslo Personal Access Token. Token vygenerujete v Account Settings; je platný jeden rok. Heslo k vašemu účtu nefunguje.

Změny se nesynchronizují automaticky: pomocí git pull získáte změny provedené v editoru a pomocí git push odešlete své. Cestu /git obsluhuje kontejner sharelatex, takže reverzní proxy před ním nepotřebuje žádné další pravidlo.

git push selže s HTTP 413 nebo curl 55 Broken pipe

Push je větší než limit velikosti nahrávání, který nastavuje MAX_UPLOAD_SIZE (v megabajtech, výchozí 50) a vztahuje se i na pushe. Zvyšte jej v config/variables.env, například MAX_UPLOAD_SIZE=200, a poté spusťte bin/up -d. Pokud používáte TLS proxy nebo vlastní reverzní proxy, zvyšte také její client_max_body_size (50M v souboru config/nginx/nginx.conf Toolkitu).

Git-bridge navíc odmítá soubory větší než 50 MB a projekty s více než 2 000 soubory. Tyto limity nastavují GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (v bajtech) a GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM v config/variables.env.

Log git-bridge zobrazuje Failed to fetch log level

Toto varování je neškodné a klonování, pull i push nadále fungují. Ve verzi 6.2.x se git-bridge jednou za minutu dotazuje metadatového serveru Google Cloud (metadata.google.internal) na úroveň logování, což funguje pouze na Google Cloud. Jinde požadavek selže, git-bridge zaloguje chybu (například null nebo stavový kód HTTP) a ponechá úroveň z GIT_BRIDGE_LOG_LEVEL. Od verze 6.3.0 je tato kontrola vypnutá a aktualizace zároveň aktualizuje image git-bridge, jehož verze odpovídá hlavnímu image.

Potřebuji pro Git a úplnou historii projektu službu track-changes nebo OVERLEAF_IS_SERVER_PRO=true?

Odpověď: Ne. Ayakaleaf Pro nemá žádnou službu track-changes. Historii projektu uchovávají služby project-history a history-v1, které vždy běží uvnitř kontejneru sharelatex. Git-bridge čte historii z history-v1 na adrese V1_HISTORY_URL (http://sharelatex:3100/api), kterou nastavuje Toolkit. OVERLEAF_IS_SERVER_PRO nenastavujte: nezávisí na ní žádná funkce, pouze přepne databázové migrace spouštěné při startu na sadu pro Server Pro.