Skip to main content
Die GitLab-Synchronisierung läuft im web-Dienst (dem Modul gitlab-sync) jedes Ayakaleaf Pro-Pods. Sie benötigt die Git-Integration. Wie Sie die OAuth-Anwendung erstellen und was die einzelnen Einstellungen bewirken, lesen Sie unter GitLab-Synchronisierung; diese Seite überträgt das auf Kubernetes.

Konfiguration

1

ConfigMap

30-config.yaml (additions)
GIT_BRIDGE_ENABLED: "true" und das git-bridge-StatefulSet aus der Git-Integration müssen vorhanden sein: Ohne sie blenden die Kontoeinstellungen und der Editor die GitLab-Synchronisierung aus.
2

Secret

GITLAB_TOKEN_CIPHER_PASSWORD verschlüsselt die GitLab-Zugriffs- und Refresh-Token der Benutzer in MongoDB. Jedes Replikat muss denselben Wert verwenden, und eine spätere Änderung zwingt alle Benutzer, GitLab erneut zu verknüpfen.
3

Private CA (optional)

Wenn Ihr GitLab ein Zertifikat Ihrer eigenen CA verwendet, fügen Sie die CA dem Secret overleaf-certs hinzu, das unter /var/lib/overleaf/certs eingebunden ist (siehe Zertifikate und andere Dateien), und setzen Sie NODE_EXTRA_CA_CERTS: /var/lib/overleaf/certs/ca.pem in der ConfigMap.
4

Anwenden, neu starten und prüfen

Jeder HTTP-Status bedeutet, dass GitLab von diesem Pod aus erreichbar ist; 000 bedeutet, dass es nicht erreichbar ist.

Mehrere Replikate

Außer dem gemeinsamen GITLAB_TOKEN_CIPHER_PASSWORD ist nichts weiter nötig. Eine Synchronisierung setzt eine Sperre in Redis, die mit den anderen Git-Synchronisierungen geteilt wird, sodass zwei Replikate nie gleichzeitig dasselbe Projekt synchronisieren. Auch das Erneuern des GitLab-Tokens eines Benutzers setzt eine Redis-Sperre, sodass zwei Replikate es nicht gleichzeitig erneuern.

Auf Kubernetes getestet

Gegen einen Mock eines selbst verwalteten GitLab unter GITLAB_SYNC_URL (vertraut über NODE_EXTRA_CA_CERTS aus overleaf-certs) bestehen auf Kubernetes 1.37 mit einem Replikat und aktivierter Git-Integration unsere End-to-End-Tests für die GitLab-Synchronisierung (40 Fälle): Verknüpfen und Trennen des Kontos, Erneuern eines ablaufenden Zugriffstokens und widerrufene Token, Export in ein neues privates oder Gruppenprojekt, Import eines Repositorys, Pull und Push, Merges, Konflikte, gelöschte und per Force-Push überschriebene Branches, Binärdateien, Umbenennungen und Löschungen sowie die Befugnisse von Besitzern, Bearbeitern und Betrachtern.
Zuletzt geändert am 2. November 2026