Git-integratie

Laat gebruikers hun projecten klonen, pullen en pushen met Git via de git-bridge.

De Git-integratie is momenteel beschikbaar in ayaka-notes/overleaf.

Deze functie is oorspronkelijk ontwikkeld door ayaka-notes/ayakaleaf-pro.

1. De git-bridge inschakelen (alleen voor Toolkit-gebruikers)

   Als je de Toolkit gebruikt, schakel je de git-bridge in door het volgende in te stellen in je config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   De Toolkit negeert dit tenzij ook SERVER_PRO=true is ingesteld. Meer is niet nodig: de Toolkit stelt GIT_BRIDGE_HOST, GIT_BRIDGE_PORT en V1_HISTORY_URL zelf in voor de container sharelatex, dus sla de twee Docker Compose-stappen hieronder over. Voer bin/up uit om de containers opnieuw aan te maken.

2. De git-bridge-container toevoegen (alleen voor Docker Compose-gebruikers)

   Gebruikers met een eigen docker-compose.yml voegen de volgende containerconfiguratie toe aan hun compose-bestand:

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

   Gebruik dezelfde tag als het image sharelatex. De MCP Server (v6.3.1 en later) maakt deel uit van het image sharelatex en wordt samen met de Git-integratie ingeschakeld, dus er is geen extra container nodig.

3. De configuratie van de sharelatex-container bijwerken

   Je moet ook de container git-bridge koppelen in de container sharelatex en de volgende omgevingsvariabelen definiëren; let daarbij goed op 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. Authenticatie

   Bij het authenticeren van een git-client hebben gebruikers een Personal Access Token nodig. Gebruikers kunnen Personal Access Tokens beheren via de gebruikersinterface van de applicatie (zie de documentatie):

   

   Personal Access Token voor de Git-integratie

5. Monitoring en resources

   We raden aan de resources van je host te monitoren nadat je de git-bridge hebt ingeschakeld. De toename van de belasting hangt af van:

   • het aantal gebruikers dat de functie gebruikt
   • de soorten projecten die op je instantie worden gehost (grotere projecten vragen over het algemeen meer resources)

​

Projecten naar S3 swappen

De Git-integratie slaat voor elk project dat door een gebruiker wordt gekloond een volledige git-repository op schijf op. Als je beperkte schijfruimte hebt, kun je een swap-job activeren die minder gebruikte repository’s naar AWS S3 verplaatst. Als een geswapte repository opnieuw nodig is, wordt deze teruggezet naar de schijf. De volgende omgevingsvariabelen bepalen de swap-job:

Naam	Beschrijving
GIT_BRIDGE_SWAPSTORE_TYPE	Stel dit in op “s3” om de swap-job te activeren.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Je AWS-toegangssleutel
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Je AWS-secret
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Deze bucket bevat de gezipte git-repository’s
GIT_BRIDGE_SWAPSTORE_AWS_REGION	De regio van de bucket
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Hoeveel projecten er minimaal op schijf moeten blijven. - Standaard: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Lage drempel voor swappen. De swap-job verplaatst projecten totdat het schijfgebruik onder deze waarde ligt. - Standaard: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Hoge drempel voor swappen. De swap-job begint met swappen wanneer het schijfgebruik deze waarde bereikt. - Standaard: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	De tijd tussen het controleren van het schijfgebruik en het uitvoeren van de swap-job. - Standaard: 3600000 ms = 1 uur

​

Vragen en antwoorden

Als ik mijn project met iemand anders deel, hoe werkt dan het rechtenmodel van de Git Bridge?

Gebruikers met alleen-lezentoegang kunnen dit project alleen klonen; gebruikers met lees- en schrijftoegang kunnen projecten klonen en pushen. Let op: gebruikers moeten aangemeld zijn om aan dit project deel te nemen.

Hoe kloon ik een project en welke gebruikersnaam en welk wachtwoord gebruik ik?

Open in de editor Integrations in de linkerbalk en klik op Git integration. Daar wordt de kloonopdracht getoond, in de vorm:

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

Wanneer Git om inloggegevens vraagt, voer je git in als gebruikersnaam en een Personal Access Token als wachtwoord. Genereer het token in Account Settings; het is één jaar geldig. Je accountwachtwoord werkt niet.

Wijzigingen worden niet automatisch gesynchroniseerd: gebruik git pull om de wijzigingen uit de editor op te halen en git push om die van jou te versturen. Het pad /git wordt aangeboden door de container sharelatex, dus een reverse proxy ervoor heeft geen extra regel nodig.

git push mislukt met HTTP 413 of curl 55 Broken pipe

De push is groter dan de limiet voor de uploadgrootte, die wordt ingesteld met MAX_UPLOAD_SIZE (in megabytes, standaard 50) en ook geldt voor pushes. Verhoog deze in config/variables.env, bijvoorbeeld MAX_UPLOAD_SIZE=200, en voer vervolgens bin/up -d uit. Als je de TLS-proxy of je eigen reverse proxy gebruikt, verhoog dan ook de client_max_body_size daarvan (50M in config/nginx/nginx.conf van de Toolkit).

De git-bridge weigert ook bestanden groter dan 50 MB en projecten met meer dan 2.000 bestanden. Deze limieten worden ingesteld met GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (in bytes) en GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM in config/variables.env.

Het git-bridge-log toont Failed to fetch log level

De waarschuwing is onschuldig, en clone, pull en push blijven werken. In 6.2.x vraagt git-bridge eenmaal per minuut een logniveau op bij de Google Cloud-metadataserver (metadata.google.internal), wat alleen op Google Cloud werkt. Elders mislukt het verzoek, logt git-bridge de fout (zoals null of een HTTP-status) en behoudt het het niveau uit GIT_BRIDGE_LOG_LEVEL. Vanaf 6.3.0 staat de controle uit, en een upgrade werkt ook het git-bridge-image bij, waarvan de versie het hoofdimage volgt.

Heb ik de track-changes-service of OVERLEAF_IS_SERVER_PRO=true nodig voor Git en de volledige projectgeschiedenis?

Antwoord: Nee. Ayakaleaf Pro heeft geen track-changes-service. De projectgeschiedenis wordt bijgehouden door de services project-history en history-v1, die altijd in de container sharelatex draaien. De git-bridge leest de geschiedenis uit history-v1 op V1_HISTORY_URL (http://sharelatex:3100/api), die de Toolkit instelt. Stel OVERLEAF_IS_SERVER_PRO niet in: geen enkele functie is ervan afhankelijk, het schakelt alleen de databasemigraties die bij het opstarten worden uitgevoerd over naar de Server Pro-set.