Синхронизация с GitLab

Позвольте пользователям синхронизировать проекты с репозиториями на GitLab.com или в самостоятельно размещённом GitLab в развёртывании на Kubernetes.

Синхронизация с GitLab работает в сервисе web (модуль gitlab-sync) каждого пода Ayakaleaf Pro. Для неё требуется интеграция с Git. Как создать OAuth-приложение и что делает каждая настройка, описано на странице Синхронизация с GitLab; эта страница переносит всё это в Kubernetes.

Сервис	web (модуль gitlab-sync) в каждом поде Ayakaleaf Pro; считывается при запуске web
Под → GitLab	REST API из GITLAB_SYNC_URL (по умолчанию https://gitlab.com/api/v4) — каждый раз, когда пользователь привязывает учётную запись, импортирует, экспортирует или синхронизирует
Браузер → GitLab	${GITLAB_SYNC_URL}/oauth/authorize для привязки учётной записи, затем возврат на ${OVERLEAF_SITE_URL}/user/gitlab-sync/oauth2/callback
GitLab → Overleaf	нет: вебхуков нет, экземпляр не обязан быть доступен из GitLab
Хранимые данные	токены доступа и обновления GitLab пользователей, в зашифрованном виде, в MongoDB
Периодические задачи	нет: синхронизация происходит, когда пользователь нажимает кнопку

​

Настройка

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" и StatefulSet git-bridge из раздела Интеграция с Git должны быть уже настроены: без них настройки учётной записи и редактор скрывают синхронизацию с 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 шифрует токены доступа и обновления GitLab пользователей в MongoDB. Все реплики должны использовать одно и то же значение, а его последующее изменение заставит каждого пользователя заново привязать GitLab.

3. Частный CA (необязательно)

   Если ваш GitLab использует сертификат, выданный вашим собственным центром сертификации (CA), добавьте сертификат CA в Secret overleaf-certs, смонтированный в /var/lib/overleaf/certs (см. Сертификаты и другие файлы), и задайте NODE_EXTRA_CA_CERTS: /var/lib/overleaf/certs/ca.pem в ConfigMap.

4. Применение, перезапуск и проверка

   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
   

   Любой HTTP-статус означает, что GitLab доступен из этого пода; 000 означает, что он недоступен.

​

Несколько реплик

Ничего дополнительного, кроме общего GITLAB_TOKEN_CIPHER_PASSWORD, не требуется. Синхронизация берёт блокировку в Redis, общую с другими Git-синхронизациями, поэтому две реплики никогда не синхронизируют один и тот же проект одновременно. Обновление токена GitLab пользователя тоже берёт блокировку в Redis, поэтому две реплики не обновляют его одновременно.

​

Проверено на Kubernetes

На макете самостоятельно размещённого GitLab по адресу GITLAB_SYNC_URL (доверие через NODE_EXTRA_CA_CERTS из overleaf-certs), в Kubernetes 1.37 с одной репликой и включённой интеграцией с Git наши сквозные тесты синхронизации с GitLab проходят (40 сценариев): привязка и отвязка учётной записи, обновление истекающего токена доступа и отозванные токены, экспорт в новый приватный проект или проект группы, импорт репозитория, pull и push, слияния, конфликты, удалённые ветки и ветки после force push, бинарные файлы, переименования и удаления, а также то, что могут делать владельцы, редакторы и читатели.