Sincronización con GitLab

Permite a los usuarios sincronizar sus proyectos con repositorios en GitLab.com o en un GitLab autogestionado en un despliegue de Kubernetes.

La sincronización con GitLab se ejecuta en el servicio web (el módulo gitlab-sync) de cada pod de Ayakaleaf Pro. Necesita la integración con Git. Crea la aplicación OAuth y consulta qué hace cada ajuste en Sincronización con GitLab; esta página lo traslada a Kubernetes.

Servicio	web (módulo gitlab-sync), en cada pod de Ayakaleaf Pro; se lee cuando web arranca
Pod → GitLab	la API REST de GITLAB_SYNC_URL (por defecto https://gitlab.com/api/v4), cada vez que un usuario vincula, importa, exporta o sincroniza
Navegador → GitLab	${GITLAB_SYNC_URL}/oauth/authorize para vincular una cuenta y, después, de vuelta a ${OVERLEAF_SITE_URL}/user/gitlab-sync/oauth2/callback
GitLab → Overleaf	ninguno: sin webhook, la instancia no necesita ser accesible desde GitLab
Datos almacenados	los tokens de acceso y de actualización de GitLab del usuario, cifrados, en MongoDB
Tareas periódicas	ninguna: la sincronización ocurre cuando un usuario hace clic

​

Configuración

1. ConfigMap

   30-config.yaml (additions)

     GITLAB_SYNC_ENABLED: "true"
     GITLAB_SYNC_CLIENT_ID: <client ID>
     # self-managed GitLab: its web address
     # GITLAB_SYNC_URL: https://gitlab.example.com
     # optional: send the module's requests to GitLab through an HTTP proxy
     # GITLAB_SYNC_PROXY_URL: http://proxy.example.com:3128
   

   GIT_BRIDGE_ENABLED: "true" y el StatefulSet de git-bridge de la integración con Git deben estar configurados: sin ellos, la configuración de la cuenta y el editor ocultan la sincronización con GitLab.

2. Secret

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

   GITLAB_TOKEN_CIPHER_PASSWORD cifra los tokens de acceso y de actualización de GitLab de los usuarios en MongoDB. Todas las réplicas deben usar el mismo valor, y cambiarlo más adelante obliga a todos los usuarios a vincular GitLab de nuevo.

3. CA privada (opcional)

   Si tu GitLab tiene un certificado de tu propia CA, añade la CA al Secret overleaf-certs montado en /var/lib/overleaf/certs (consulta Certificados y otros archivos) y establece NODE_EXTRA_CA_CERTS: /var/lib/overleaf/certs/ca.pem en el ConfigMap.

4. Aplicar, reiniciar y comprobar

   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://gitlab.com/api/v4/version
   done
   

   Cualquier código de estado HTTP significa que GitLab es accesible desde ese pod; 000 significa que no lo es.

​

Varias réplicas

No hace falta nada más aparte del GITLAB_TOKEN_CIPHER_PASSWORD compartido. Una sincronización toma un bloqueo en Redis, compartido con las demás sincronizaciones de Git, de modo que dos réplicas nunca sincronizan el mismo proyecto a la vez. Actualizar el token de GitLab de un usuario también toma un bloqueo en Redis, de modo que dos réplicas no lo actualizan al mismo tiempo.

​

Probado en Kubernetes

Contra un simulacro de un GitLab autogestionado en GITLAB_SYNC_URL (de confianza a través de NODE_EXTRA_CA_CERTS desde overleaf-certs), en Kubernetes 1.37 con una réplica y la integración con Git activada, nuestras pruebas de extremo a extremo de la sincronización con GitLab se superan (40 casos): vincular y desvincular la cuenta, actualizar un token de acceso que caduca y tokens revocados, exportar a un nuevo proyecto privado o de grupo, importar un repositorio, pull y push, fusiones, conflictos, ramas eliminadas y con push forzado, archivos binarios, cambios de nombre y eliminaciones, y lo que pueden hacer los propietarios, editores y lectores.