Gitea-Synchronisierung

Benutzern in einem Kubernetes-Deployment ermöglichen, ihre Projekte mit Repositorys auf Gitea.com oder Ihrem eigenen Gitea zu synchronisieren.

Die Gitea-Synchronisierung läuft im web-Dienst (dem gitea-sync-Modul) jedes Ayakaleaf-Pro-Pods. Sie benötigt die Git-Integration. Erstellen Sie die OAuth-Anwendung und lesen Sie, was jede Einstellung bewirkt, unter Gitea-Synchronisierung; diese Seite überträgt das auf Kubernetes.

Dienst	web (gitea-sync-Modul), in jedem Ayakaleaf-Pro-Pod; beim Start von web gelesen
Pod → Gitea	die REST-API von GITEA_SYNC_URL (Standard https://gitea.com/api/v1), immer wenn ein Benutzer verknüpft, importiert, exportiert oder synchronisiert
Browser → Gitea	${GITEA_SYNC_URL}/login/oauth/authorize zum Verknüpfen eines Kontos, dann zurück zu ${OVERLEAF_SITE_URL}/user/gitea-sync/oauth2/callback
Gitea → Overleaf	keine: kein Webhook, die Instanz muss von Gitea aus nicht erreichbar sein
Gespeicherte Daten	die Gitea-Access- und Refresh-Tokens des Benutzers, verschlüsselt, in MongoDB
Periodische Jobs	keine: Die Synchronisierung erfolgt, wenn ein Benutzer klickt

​

Konfiguration

1. ConfigMap

   30-config.yaml (additions)

     GITEA_SYNC_ENABLED: "true"
     GITEA_SYNC_CLIENT_ID: <client ID>
     # your own Gitea: its ROOT_URL
     # GITEA_SYNC_URL: https://gitea.example.com
     # optional: send the module's requests to Gitea through an HTTP proxy
     # GITEA_SYNC_PROXY_URL: http://proxy.example.com:3128
   

   GIT_BRIDGE_ENABLED: "true" und das git-bridge-StatefulSet aus Git-Integration müssen vorhanden sein: Ohne sie blenden die Kontoeinstellungen und der Editor die Gitea-Synchronisierung aus.

2. Secret

   kubectl -n overleaf patch secret overleaf-secrets --type merge -p '{"stringData":{
     "GITEA_SYNC_CLIENT_SECRET":"<client secret>",
     "GITEA_TOKEN_CIPHER_PASSWORD":"'"$(openssl rand -hex 32)"'"}}'
   

   GITEA_TOKEN_CIPHER_PASSWORD verschlüsselt die Gitea-Access- und Refresh-Tokens der Benutzer in MongoDB. Jedes Replikat muss denselben Wert verwenden, und eine spätere Änderung zwingt jeden Benutzer, Gitea erneut zu verknüpfen.

3. Private CA (optional)

   Wenn Ihr Gitea ein Zertifikat Ihrer eigenen CA hat, fügen Sie die CA zum Secret overleaf-certs hinzu, das unter /var/lib/overleaf/certs eingehängt 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

   kubectl apply -f 30-config.yaml
   kubectl -n overleaf rollout restart deployment/overleaf     # or statefulset/overleaf
   for p in $(kubectl -n overleaf get pod -l app=overleaf -o name); do   # app=overleaf-ha for several replicas
     kubectl -n overleaf exec "$p" -- curl -sS -o /dev/null -w "$p %{http_code}\n" https://gitea.com/api/v1/version
   done
   

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

​

Mehrere Replikate

Über das gemeinsame GITEA_TOKEN_CIPHER_PASSWORD hinaus nichts weiter. Eine Synchronisierung setzt eine Sperre in Redis, die mit den anderen Git-Synchronisierungen geteilt wird, sodass zwei Replikate nie gleichzeitig dasselbe Projekt synchronisieren.

​

Getestet auf Kubernetes

Gegen ein echtes Gitea 1.23 unter GITEA_SYNC_URL bestehen auf Kubernetes 1.37 mit einem Replikat und aktivierter Git-Integration unsere End-to-End-Tests für die Gitea-Synchronisierung (39 Fälle): Verknüpfen und Trennen des Kontos über Giteas OAuth2, Erneuern des ablaufenden Access-Tokens und widerrufene Berechtigungen, Export in ein neues privates oder Organisations-Repository, Import eines Repositorys, Pull und Push, Merges, Konflikte, gelöschte und per Force-Push überschriebene Branches, Binärdateien, Umbenennungen und Löschungen sowie das, was Eigentümer, Bearbeiter und Betrachter tun dürfen.