GitLab-synkronisering

Denne funktion er udviklet af ayaka-notes/ayakaleaf-pro. Den er introduceret i v6.4.0 og senere. Den er stadig i betastatus. Vi har brug for din feedback, hvis du oplever problemer.

GitLab-synkronisering fungerer ligesom GitHub-synkronisering: brugerne forbinder deres GitLab-konto, eksporterer projekter til nye GitLab-projekter, importerer GitLab-repositories og synkroniserer ændringer i begge retninger. Den fungerer med GitLab.com og med selvadministreret GitLab 15.10 eller nyere (Community og Enterprise Edition).

​

Opsætning af GitLab-synkronisering

Du skal først aktivere git-bridge, før du kan bruge GitLab-synkronisering.

config/overleaf.rc

GIT_BRIDGE_ENABLED=true

Opret en OAuth-applikation på din GitLab-instans under User settings → Applications (eller Admin area → Applications for en applikation, der gælder for hele instansen):

• Redirect URI: ${OVERLEAF_SITE_URL}/user/gitlab-sync/oauth2/callback
• Confidential: markeret
• Scopes: api

Kopiér Application ID og Secret, og tilføj derefter følgende indstillinger til dine Overleaf-miljøvariabelfiler.

config/variables.env

# used to encrypt the user's GitLab access and refresh tokens.
# How to generate: `openssl rand -hex 32`
GITLAB_TOKEN_CIPHER_PASSWORD=0123456789ABCDEFG # changed to yours

# GitLab Sync Settings
GITLAB_SYNC_ENABLED=true
GITLAB_SYNC_CLIENT_ID=
GITLAB_SYNC_CLIENT_SECRET=

# Web address of your GitLab, defaults to https://gitlab.com
# GITLAB_SYNC_URL=https://gitlab.example.com

# OAuth callback is: ${OVERLEAF_SITE_URL}/user/gitlab-sync/oauth2/callback
# (Optional) GITLAB_SYNC_PROXY_URL=http://10.0.0.1:10808

Før du konfigurerer GitLab OAuth-redirect-URI’en, skal du sikre dig, at OVERLEAF_SITE_URL er sat korrekt.

GitLab-adgangstokens udløber efter to timer. Overleaf fornyer dem med det refresh-token, som GitLab udsteder sammen med dem, så brugerne forbliver forbundet, indtil de fjerner forbindelsen eller tilbagekalder applikationen i GitLab.

​

Selvadministreret GitLab

Sæt GITLAB_SYNC_URL til webadressen for din instans, den adresse du åbner projekter med i browseren. REST API’et udledes af den:

Variabel	Standard
GITLAB_SYNC_URL	https://gitlab.com
GITLAB_SYNC_API_URL	${GITLAB_SYNC_URL}/api/v4

Sæt kun GITLAB_SYNC_API_URL, hvis din instans udstiller API’et et andet sted, for eksempel bag en API-gateway.

• Opret OAuth-applikationen på den instans, du angiver i GITLAB_SYNC_URL. En applikation fra gitlab.com virker ikke på en selvadministreret instans.
• GITLAB_SYNC_URL er kun webadressen. Tilføj ikke /api/v4 eller en gruppesti.

Hvis din instans bruger et certifikat fra en privat CA, skal du montere CA-certifikatet i containeren og pege NODE_EXTRA_CA_CERTS på det, f.eks. NODE_EXTRA_CA_CERTS=/var/lib/overleaf/certs/gitlab-ca.pem.

Forbundne konti og projekter hører til den instans, de blev forbundet med. Før du skifter GITLAB_SYNC_URL til en anden instans, skal du bede brugerne om at fjerne forbindelsen til deres GitLab-konto og projekter.

Hvis du befinder dig i en region med begrænset netværksadgang, kan det være nødvendigt at konfigurere en proxy for at få adgang til GitLab. Sæt følgende miljøvariabel: GITLAB_SYNC_PROXY_URL=http://10.0.0.1:10808. Det skal være en almindelig HTTP/HTTPS-videresendelsesproxy, og den må ikke bruge 127.0.0.1.

​

Hvem kan forbinde og synkronisere

Ligesom på Overleaf Cloud kan kun projektejeren forbinde et projekt med et GitLab-repository. Når det er forbundet, kan alle samarbejdspartnere med redigeringsadgang synkronisere det.

Handling	Hvem kan gøre det
Eksportere et projekt til et nyt GitLab-repository	Projektejeren
Importere et GitLab-repository til et nyt projekt	Enhver bruger, som bliver ejer af det nye projekt
Pull, push og merge af et forbundet projekt	Ejeren og samarbejdspartnere med redigeringsadgang
Fjerne forbindelsen mellem et projekt og dets repository	Projektejeren

• Overleaf kommunikerer med GitLab via GitLab-kontoen for den bruger, der synkroniserer, så alle samarbejdspartnere, der synkroniserer, forbinder deres egen GitLab-konto og skal have tilladelse til at pushe til repositoryets standardbranch.
• Samarbejdspartnere med kun læseadgang kan ikke bruge GitLab-synkronisering for projektet.

​

Sådan fungerer synkronisering med GitLab

• Tilladelser: brugerne skal have tilladelse til at pushe til det forbundne projekts standardbranch. Når standardbranchen er beskyttet, og brugeren ikke må pushe til den, beder Overleaf dem om at kontakte projektejeren, ligesom ved et repository, de har mistet adgangen til.
• Merging: når et projekt er ændret både i Overleaf og i GitLab, committer Overleaf sine ændringer til en midlertidig branch ved navn overleaf-YYYY-MM-DD-HHMMSS og merger den via en merge request, fordi GitLab ikke har noget API til at merge branches uden. Efter mergen sletter Overleaf den midlertidige branch og merge requesten. Kun administratorer og projektejere må slette merge requests i GitLab, så for andre brugere forbliver den mergede merge request i projektet.
• Merge-regler: Overleaf omgår aldrig projektets merge-regler. Når merge requesten har en konflikt eller kræver en godkendelse eller en bestået pipeline, forbliver den åben, og Overleaf beder brugeren om at merge den i GitLab og derefter fortsætte synkroniseringen.
• Pipelines: commits fra Overleaf starter pipelines ligesom alle andre commits. Hvis dit projekt kører pipelines for merge requests og kræver, at de bestås, venter merges fra Overleaf på dem, som beskrevet ovenfor.

​

Q&A

Kan jeg force-pushe til standardbranchen?

Svar: Hold venligst force push til standardbranchen deaktiveret. Det er GitLabs standard: standardbranchen i et nyt projekt er beskyttet, og ingen kan force-pushe til den. Overleaf kan overtage en omskrevet branch, men GitLab-synkronisering er designet til en standardbranch, hvis historik kun vokser.

Kan jeg omdøbe standardbranchen i et forbundet projekt?

Svar: Nej. Overleaf fortsætter med at synkronisere med den branch, projektet blev forbundet med, så synkroniseringer mislykkes, når den branch omdøbes eller fjernes. For at synkronisere med en anden branch skal du fjerne forbindelsen til projektet og derefter importere repositoryet i et nyt projekt, som bruger den aktuelle standardbranch.