Git-integration

Låt användare klona, hämta och pusha sina projekt med Git via git-bridge.

Git-integrationen är för närvarande tillgänglig i ayaka-notes/overleaf.

Den här funktionen utvecklades ursprungligen av ayaka-notes/ayakaleaf-pro.

1. Aktivera git-bridge (endast för Toolkit-användare)

   Om du använder Toolkit aktiverar du git-bridge genom att ange följande i din config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   Toolkit ignorerar den om inte även SERVER_PRO=true är satt. Inget mer behövs: Toolkit sätter själv GIT_BRIDGE_HOST, GIT_BRIDGE_PORT och V1_HISTORY_URL för containern sharelatex, så hoppa över de två Docker Compose-stegen nedan. Kör bin/up för att återskapa containrarna.

2. Lägg till git-bridge-containern (endast för Docker-compose-användare)

   Användare som kör en egen docker-compose.yml lägger till följande containerkonfiguration i sin compose-fil:

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

   Använd samma tagg som för sharelatex-imagen. MCP-servern (v6.3.1 och senare) ingår i sharelatex-imagen och aktiveras tillsammans med Git-integrationen, så den behöver ingen extra container.

3. Uppdatera konfigurationen för sharelatex-containern

   Du behöver också länka git-bridge-containern i sharelatex-containern och definiera följande miljövariabler. Var särskilt uppmärksam på 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. Autentisering

   När en git-klient ska autentiseras behöver användarna en personlig åtkomsttoken (Personal Access Token). Användarna kan hantera sina personliga åtkomsttoken via applikationens gränssnitt (se dokumentationen):

   

   Personlig åtkomsttoken för Git-integrationen

5. Övervakning och resursöverväganden

   Vi rekommenderar att du övervakar värdens resurser efter att du har aktiverat git-bridge. Hur mycket belastningen ökar beror på:

   • antalet användare som använder funktionen
   • vilka typer av projekt som finns i din instans (större projekt är i allmänhet mer resurskrävande)

​

Flytta projekt till S3

Git-integrationen lagrar ett fullständigt git-repository på disk för varje projekt som klonas av en användare. Om du har begränsat diskutrymme kan du aktivera ett swap-jobb som flyttar mindre använda repositories till AWS S3. Om ett utflyttat repository behövs igen flyttas det tillbaka till disken. Följande miljövariabler styr swap-jobbet:

Namn	Beskrivning
GIT_BRIDGE_SWAPSTORE_TYPE	Ange “s3” för att aktivera swap-jobbet.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Din AWS-åtkomstnyckel
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Din AWS-hemlighet
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Den här bucketen kommer att innehålla de zippade git-repositoryna
GIT_BRIDGE_SWAPSTORE_AWS_REGION	Bucketens region
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Minsta antal projekt som ska behållas på disk. - Standard: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Lägre gränsvärde för swapping. Swap-jobbet flyttar projekt tills diskanvändningen understiger detta värde. - Standard: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Övre gränsvärde för swapping. Swap-jobbet börjar flytta projekt när diskanvändningen når detta värde. - Standard: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	Tiden mellan kontrollerna av diskanvändningen och körningarna av swap-jobbet. - Standard: 3600000 ms = 1 timme

​

Frågor och svar

Hur fungerar behörighetsmodellen i Git Bridge om jag delar mitt projekt med någon annan?

Användare med skrivskyddad åtkomst kan endast klona projektet; användare med läs- och skrivåtkomst kan både klona och pusha projekt. Obs! Användarna måste vara inloggade för att gå med i projektet.

Hur klonar jag ett projekt, och vilket användarnamn och lösenord ska jag använda?

I redigeraren öppnar du Integrations i den vänstra listen och klickar på Git integration. Där visas klonkommandot, på formen:

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

När Git frågar efter inloggningsuppgifter anger du git som användarnamn och en personlig åtkomsttoken (Personal Access Token) som lösenord. Generera token under Account Settings; den är giltig i ett år. Ditt kontolösenord fungerar inte.

Ändringar synkroniseras inte automatiskt: använd git pull för att hämta ändringarna som gjorts i redigeraren och git push för att skicka dina. Sökvägen /git serveras av sharelatex-containern, så en omvänd proxy framför den behöver ingen extra regel.

git push misslyckas med HTTP 413 eller curl 55 Broken pipe

Pushen är större än gränsen för uppladdningsstorlek, som anges med MAX_UPLOAD_SIZE (i megabyte, 50 som standard) och även gäller för pushar. Höj den i config/variables.env, till exempel MAX_UPLOAD_SIZE=200, och kör sedan bin/up -d. Om du använder TLS-proxyn eller en egen omvänd proxy höjer du även dess client_max_body_size (50M i Toolkits config/nginx/nginx.conf).

git-bridge avvisar även filer större än 50 MB och projekt med fler än 2 000 filer. Dessa gränser anges med GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (i byte) och GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM i config/variables.env.

git-bridge-loggen visar Failed to fetch log level

Varningen är ofarlig, och clone, pull och push fortsätter att fungera. I 6.2.x frågar git-bridge Google Clouds metadataserver (metadata.google.internal) efter en loggnivå en gång i minuten, vilket bara fungerar på Google Cloud. På andra ställen misslyckas förfrågan, git-bridge loggar felet (till exempel null eller en HTTP-status) och behåller nivån från GIT_BRIDGE_LOG_LEVEL. Från 6.3.0 är kontrollen avstängd, och en uppgradering uppdaterar även git-bridge-imagen, vars version följer huvudimagen.

Behöver jag tjänsten track-changes eller OVERLEAF_IS_SERVER_PRO=true för Git och fullständig projekthistorik?

Svar: Nej. Ayakaleaf Pro har ingen track-changes-tjänst. Projekthistoriken hanteras av tjänsterna project-history och history-v1, som alltid körs inuti containern sharelatex. git-bridge läser historiken från history-v1 på V1_HISTORY_URL (http://sharelatex:3100/api), som Toolkit sätter. Sätt inte OVERLEAF_IS_SERVER_PRO: ingen funktion är beroende av den, den växlar bara de databasmigreringar som körs vid start till uppsättningen för Server Pro.