Git-integration

Lad brugere klone, pulle og pushe deres projekter med Git via git-bridge.

Git-integrationen er i øjeblikket tilgængelig i ayaka-notes/overleaf.

Denne funktion er oprindeligt udviklet af ayaka-notes/ayakaleaf-pro.

1. Aktivér git-bridge (kun for Toolkit-brugere)

   Hvis du bruger Toolkit, skal du aktivere git-bridge ved at angive følgende i din config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   Toolkit ignorerer den, medmindre SERVER_PRO=true også er sat. Der kræves ikke andet: Toolkit sætter selv GIT_BRIDGE_HOST, GIT_BRIDGE_PORT og V1_HISTORY_URL for sharelatex-containeren, så spring de to Docker Compose-trin nedenfor over. Kør bin/up for at genoprette containerne.

2. Tilføj git-bridge-containeren (kun for Docker Compose-brugere)

   Brugere, der kører en brugerdefineret docker-compose.yml, skal tilføje følgende containerkonfiguration til deres 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"]
   

   Brug samme tag som sharelatex-imaget. MCP-serveren (v6.3.1 og nyere) er en del af sharelatex-imaget og aktiveres sammen med Git-integrationen, så den kræver ingen ekstra container.

3. Opdater konfigurationen af sharelatex-containeren

   Du skal også linke git-bridge-containeren i sharelatex-containeren og definere følgende miljøvariabler. Vær opmærksom 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. Godkendelse

   Når en git-klient skal godkendes, har brugerne brug for et Personal Access Token. Brugerne kan administrere Personal Access Tokens via applikationens brugerflade (se dokumentationen):

   

   Personal Access Token til Git-integration

5. Overvågning og ressourcehensyn

   Vi anbefaler, at du overvåger din værts ressourcer, efter at du har aktiveret git-bridge. Belastningsstigningen afhænger af:

   • antallet af brugere, der bruger funktionen
   • de typer projekter, der hostes på din instans (større projekter er generelt mere ressourcekrævende)

​

Flytning af projekter til S3

Git-integrationen gemmer et komplet git-repository på disken for hvert projekt, som en bruger kloner. Hvis du har begrænset diskplads, kan du aktivere et swap-job, der flytter mindre brugte repositories til AWS S3. Hvis der igen er brug for et flyttet repository, bliver det flyttet tilbage til disken. Følgende miljøvariabler styrer swap-jobbet:

Navn	Beskrivelse
GIT_BRIDGE_SWAPSTORE_TYPE	Sæt denne til “s3” for at aktivere swap-jobbet.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Din AWS-adgangsnøgle
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Din AWS-secret
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Denne bucket vil indeholde de zippede git-repositories
GIT_BRIDGE_SWAPSTORE_AWS_REGION	Bucketens region
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Hvor mange projekter der som minimum skal beholdes på disken. - Standard: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Nedre grænse for swapping. Swap-jobbet flytter projekter, indtil diskforbruget er under denne værdi. - Standard: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Øvre grænse for swapping. Swap-jobbet begynder at swappe, når diskforbruget når denne værdi. - Standard: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	Tiden mellem kontrol af diskforbrug og kørsel af swap-jobbet. - Standard: 3600000 ms = 1 time

​

Spørgsmål og svar

Hvis jeg deler mit projekt med en anden, hvordan fungerer rettighedsmodellen i Git Bridge så?

Brugere med skrivebeskyttet adgang kan kun klone projektet; brugere med læse- og skriveadgang kan klone og pushe projekter. Bemærk: Brugere skal være logget ind for at kunne deltage i projektet.

Hvordan kloner jeg et projekt, og hvilket brugernavn og hvilken adgangskode skal jeg bruge?

Åbn Integrations i editorens venstre panel, og klik på Git integration. Den viser klonkommandoen på formen:

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

Når Git beder om legitimationsoplysninger, skal du angive git som brugernavn og et Personal Access Token som adgangskode. Generér tokenet under Account Settings; det er gyldigt i ét år. Din kontoadgangskode virker ikke.

Ændringer synkroniseres ikke automatisk: brug git pull til at hente de ændringer, der er foretaget i editoren, og git push til at sende dine egne. Stien /git serveres af sharelatex-containeren, så en reverse proxy foran den kræver ingen ekstra regel.

git push mislykkes med HTTP 413 eller curl 55 Broken pipe

Pushet er større end grænsen for uploadstørrelse, som sættes med MAX_UPLOAD_SIZE (i megabyte, 50 som standard) og også gælder for pushes. Hæv den i config/variables.env, for eksempel MAX_UPLOAD_SIZE=200, og kør derefter bin/up -d. Hvis du bruger TLS-proxyen eller din egen reverse proxy, skal du også hæve dens client_max_body_size (50M i Toolkits config/nginx/nginx.conf).

Git-bridge afviser også filer større end 50 MB og projekter med mere end 2.000 filer. Disse grænser sættes med GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (i bytes) og GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM i config/variables.env.

git-bridge-loggen viser Failed to fetch log level

Advarslen er harmløs, og clone, pull og push fungerer fortsat. I 6.2.x spørger git-bridge Google Clouds metadataserver (metadata.google.internal) om et logniveau én gang i minuttet, hvilket kun virker på Google Cloud. Andre steder mislykkes forespørgslen, git-bridge logger fejlen (såsom null eller en HTTP-status) og beholder niveauet fra GIT_BRIDGE_LOG_LEVEL. Fra og med 6.3.0 er kontrollen slået fra, og en opgradering opdaterer også git-bridge-imaget, hvis version følger hovedimaget.

Har jeg brug for track-changes-tjenesten eller OVERLEAF_IS_SERVER_PRO=true for Git og fuld projekthistorik?

Svar: Nej. Ayakaleaf Pro har ingen track-changes-tjeneste. Projekthistorikken opbevares af tjenesterne project-history og history-v1, som altid kører inde i sharelatex-containeren. git-bridge læser historikken fra history-v1 på V1_HISTORY_URL (http://sharelatex:3100/api), som Toolkit sætter. Sæt ikke OVERLEAF_IS_SERVER_PRO: ingen funktion afhænger af den, den skifter kun de databasemigreringer, der køres ved opstart, til Server Pro-sættet.