Git-integrasjon

La brukere klone, hente og pushe prosjektene sine med Git via git-bridge.

Git-integrasjonen er foreløpig tilgjengelig i ayaka-notes/overleaf.

Denne funksjonen ble opprinnelig utviklet av ayaka-notes/ayakaleaf-pro.

1. Aktiver git-bridge (kun for Toolkit-brukere)

   Hvis du bruker Toolkit, aktiverer du git-bridge ved å angi følgende i config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   Toolkit ignorerer den med mindre SERVER_PRO=true også er satt. Ingenting annet trengs: Toolkit setter selv GIT_BRIDGE_HOST, GIT_BRIDGE_PORT og V1_HISTORY_URL for sharelatex-containeren, så hopp over de to Docker Compose-trinnene nedenfor. Kjør bin/up for å gjenopprette containerne.

2. Legg til git-bridge-containeren (kun for Docker-compose-brukere)

   Brukere som kjører en egendefinert docker-compose.yml, legger til følgende containerkonfigurasjon i compose-filen sin:

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

   Bruk samme tag som sharelatex-imaget. MCP-serveren (v6.3.1 og nyere) er en del av sharelatex-imaget og aktiveres sammen med Git-integrasjonen, så den trenger ingen ekstra container.

3. Oppdater konfigurasjonen av sharelatex-containeren

   Du må også koble git-bridge-containeren til sharelatex-containeren og definere følgende miljøvariabler. Vær spesielt oppmerksom 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

   Ved autentisering av en git-klient trenger brukerne et personlig tilgangstoken (Personal Access Token). Brukerne kan administrere personlige tilgangstokener i applikasjonens brukergrensesnitt (se dokumentasjonen):

   

   Personlig tilgangstoken for Git-integrasjon

5. Overvåking og ressurshensyn

   Vi anbefaler at du overvåker ressursene på verten etter at du har aktivert git-bridge. Økningen i belastning avhenger av:

   • antall brukere som bruker funksjonen
   • hvilke typer prosjekter som ligger i instansen din (større prosjekter krever generelt mer ressurser)

​

Flytte prosjekter til S3 (swap)

Git-integrasjonen lagrer et komplett git-repository på disk for hvert prosjekt som en bruker kloner. Hvis du har begrenset diskplass, kan du aktivere en swap-jobb som flytter repositorier som brukes sjeldnere, til AWS S3. Hvis et flyttet repository trengs igjen, flyttes det tilbake til disken. Følgende miljøvariabler styrer swap-jobben:

Navn	Beskrivelse
GIT_BRIDGE_SWAPSTORE_TYPE	Sett denne til “s3” for å aktivere swap-jobben.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	AWS-tilgangsnøkkelen din
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	AWS-hemmeligheten din
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Denne bucketen vil inneholde de zippede git-repositoriene
GIT_BRIDGE_SWAPSTORE_AWS_REGION	Bucketens region
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Minste antall prosjekter som skal beholdes på disk. - Standard: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Nedre terskel for swapping. Swap-jobben flytter prosjekter til diskbruken er under denne verdien. - Standard: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Øvre terskel for swapping. Swap-jobben begynner å flytte når diskbruken når denne verdien. - Standard: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	Tiden mellom hver kontroll av diskbruk og kjøring av swap-jobben. - Standard: 3600000 ms = 1 time

​

Spørsmål og svar

Hvis jeg deler prosjektet mitt med noen andre, hvordan fungerer tillatelsesmodellen i Git Bridge?

Brukere med skrivebeskyttet tilgang kan bare klone prosjektet; brukere med lese- og skrivetilgang kan klone og pushe prosjekter. Merk: Brukerne må være logget inn for å bli med i prosjektet.

Hvordan kloner jeg et prosjekt, og hvilket brukernavn og passord bruker jeg?

I editoren åpner du Integrations i venstre felt og klikker Git integration. Der vises klonekommandoen, på formen:

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

Når Git ber om legitimasjon, skriver du inn git som brukernavn og et personlig tilgangstoken (Personal Access Token) som passord. Generer tokenet i Account Settings; det er gyldig i ett år. Kontopassordet ditt fungerer ikke.

Endringer synkroniseres ikke automatisk: bruk git pull for å hente endringene som er gjort i editoren, og git push for å sende dine. Stien /git serveres av sharelatex-containeren, så en reverse proxy foran den trenger ingen ekstra regel.

git push mislykkes med HTTP 413 eller curl 55 Broken pipe

Pushen er større enn grensen for opplastingsstørrelse, som angis med MAX_UPLOAD_SIZE (i megabyte, 50 som standard) og også gjelder for push. Øk den i config/variables.env, for eksempel MAX_UPLOAD_SIZE=200, og kjør deretter bin/up -d. Hvis du bruker TLS-proxyen eller din egen reverse proxy, må du også øke client_max_body_size der (50M i Toolkits config/nginx/nginx.conf).

Git-bridge avviser også filer større enn 50 MB og prosjekter med mer enn 2 000 filer. Disse grensene angis med GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (i byte) og GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM i config/variables.env.

Git-bridge-loggen viser Failed to fetch log level

Advarselen er ufarlig, og clone, pull og push fortsetter å fungere. I 6.2.x spør git-bridge metadataserveren til Google Cloud (metadata.google.internal) om et loggnivå én gang i minuttet, noe som bare fungerer på Google Cloud. Andre steder mislykkes forespørselen, git-bridge logger feilen (for eksempel null eller en HTTP-status) og beholder nivået fra GIT_BRIDGE_LOG_LEVEL. Fra og med 6.3.0 er sjekken slått av, og en oppgradering oppdaterer også git-bridge-imaget, hvis versjon følger hovedimaget.

Trenger jeg track-changes-tjenesten eller OVERLEAF_IS_SERVER_PRO=true for Git og full prosjekthistorikk?

Svar: Nei. Ayakaleaf Pro har ingen track-changes-tjeneste. Prosjekthistorikken håndteres av tjenestene project-history og history-v1, som alltid kjører inne i sharelatex-containeren. Git-bridge leser historikk fra history-v1 på V1_HISTORY_URL (http://sharelatex:3100/api), som Toolkit setter. Ikke sett OVERLEAF_IS_SERVER_PRO: ingen funksjon er avhengig av den, den bytter bare databasemigreringene som kjøres ved oppstart, til Server Pro-settet.