Интеграция с Git

Позвольте пользователям клонировать, получать и отправлять свои проекты с помощью Git через git-bridge.

В настоящее время интеграция с Git доступна в ayaka-notes/overleaf.

Эта функция изначально разработана ayaka-notes/ayakaleaf-pro.

1. Включение git-bridge (только для пользователей Toolkit)

   Если вы используете Toolkit, включите git-bridge, задав следующий параметр в файле config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   Toolkit игнорирует этот параметр, если не задан также SERVER_PRO=true. Больше ничего не требуется: Toolkit сам задаёт GIT_BRIDGE_HOST, GIT_BRIDGE_PORT и V1_HISTORY_URL для контейнера sharelatex, поэтому пропустите два шага для Docker Compose ниже. Выполните bin/up, чтобы пересоздать контейнеры.

2. Добавление контейнера git-bridge (только для пользователей Docker-compose)

   Если вы используете собственный docker-compose.yml, добавьте в compose-файл следующую конфигурацию контейнера:

   docker-compose.yml (git-bridge service)

   git-bridge:
       restart: always
       image: ghcr.io/ayaka-notes/overleaf-pro/git-bridge:6.3.2 # tag should match the `sharelatex` container tag
       volumes:
           - ~/git_bridge_data:/data/git-bridge
       container_name: git-bridge
       expose:
           - "8000"
       environment:
           GIT_BRIDGE_API_BASE_URL: "http://sharelatex:3000/api/v0/" 
           GIT_BRIDGE_OAUTH2_SERVER: "http://sharelatex"
           GIT_BRIDGE_POSTBACK_BASE_URL: "http://git-bridge:8000"
           GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
       user: root
       command: ["/server-pro-start.sh"]
   

   Используйте тот же тег, что и у образа sharelatex. MCP Server (v6.3.1 и новее) входит в образ sharelatex и включается вместе с интеграцией с Git, поэтому дополнительный контейнер для него не нужен.

3. Обновление конфигурации контейнера sharelatex

   Также необходимо связать контейнер git-bridge с контейнером sharelatex и задать следующие переменные окружения. Обратите особое внимание на V1_HISTORY_URL:

   docker-compose.yml (sharelatex service)

   sharelatex:
       links:
           - git-bridge
       environment:
            GIT_BRIDGE_ENABLED: true
            GIT_BRIDGE_HOST: "git-bridge"
            GIT_BRIDGE_PORT: "8000"
            # We use v1 now, if you used to set V1_HISTORY_URL, please update now
            V1_HISTORY_URL: "http://sharelatex:3100/api"
   
4. Аутентификация

   Для аутентификации git-клиента пользователям нужен персональный токен доступа (Personal Access Token). Пользователи могут управлять персональными токенами доступа через интерфейс приложения (см. документацию):

   

   Персональный токен доступа для интеграции с Git

5. Мониторинг и потребление ресурсов

   После включения git-bridge рекомендуем отслеживать ресурсы хоста. Рост нагрузки будет зависеть от:

   • количества пользователей, использующих эту функцию
   • типов проектов, размещённых в вашем экземпляре (более крупные проекты, как правило, требуют больше ресурсов)

​

Перенос проектов в S3

Интеграция с Git хранит на диске полный git-репозиторий для каждого проекта, который клонирует пользователь. Если место на диске ограничено, можно включить задание подкачки (swap job), которое будет переносить редко используемые репозитории в AWS S3. Если перенесённый репозиторий снова понадобится, он будет возвращён на диск. Задание подкачки управляется следующими переменными окружения:

Имя	Описание
GIT_BRIDGE_SWAPSTORE_TYPE	Задайте значение “s3”, чтобы включить задание подкачки.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Ваш ключ доступа AWS
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Ваш секретный ключ AWS
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	В этом бакете будут храниться заархивированные git-репозитории
GIT_BRIDGE_SWAPSTORE_AWS_REGION	Регион бакета
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Минимальное количество проектов, хранящихся на диске. - По умолчанию: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Нижний порог подкачки. Задание подкачки переносит проекты, пока использование диска не опустится ниже этого значения. - По умолчанию: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Верхний порог подкачки. Задание подкачки начинает перенос, когда использование диска достигает этого значения. - По умолчанию: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	Интервал между проверками использования диска и запусками задания подкачки. - По умолчанию: 3600000 ms = 1 час

​

Вопросы и ответы

Если я поделюсь проектом с другим пользователем, как работает модель прав доступа Git Bridge?

Пользователи с доступом только для чтения могут лишь клонировать проект; пользователи с доступом на чтение и запись могут клонировать проект и отправлять в него изменения (push). Примечание: чтобы присоединиться к проекту, пользователям необходимо войти в систему.

Как клонировать проект и какие имя пользователя и пароль использовать?

В редакторе откройте Integrations на левой панели и нажмите Git integration. Там показана команда клонирования вида:

git clone https://<your-overleaf>/git/<project_id>

Когда Git запросит учётные данные, введите git в качестве имени пользователя и Personal Access Token в качестве пароля. Сгенерируйте токен в Account Settings; он действителен один год. Пароль вашей учётной записи не подойдёт.

Изменения не синхронизируются автоматически: используйте git pull, чтобы получить изменения, сделанные в редакторе, и git push, чтобы отправить свои. Путь /git обслуживается контейнером sharelatex, поэтому обратному прокси перед ним не нужно дополнительное правило.

git push завершается ошибкой HTTP 413 или curl 55 Broken pipe

Объём push превышает лимит размера загрузки, который задаётся MAX_UPLOAD_SIZE (в мегабайтах, по умолчанию 50) и распространяется также на push. Увеличьте его в config/variables.env, например MAX_UPLOAD_SIZE=200, затем выполните bin/up -d. Если вы используете TLS-прокси или собственный обратный прокси, также увеличьте его client_max_body_size (50M в файле config/nginx/nginx.conf из Toolkit).

Git-bridge также отклоняет файлы размером более 50 МБ и проекты с более чем 2000 файлов. Эти лимиты задаются переменными GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (в байтах) и GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM в config/variables.env.

В логе git-bridge отображается Failed to fetch log level

Это предупреждение безвредно: clone, pull и push продолжают работать. В 6.2.x git-bridge раз в минуту запрашивает уровень логирования у сервера метаданных Google Cloud (metadata.google.internal), что работает только в Google Cloud. В других средах запрос завершается ошибкой, git-bridge записывает её в лог (например, null или HTTP-статус) и сохраняет уровень из GIT_BRIDGE_LOG_LEVEL. Начиная с 6.3.0 эта проверка отключена, а при обновлении также обновляется образ git-bridge, версия которого следует за основным образом.

Нужны ли сервис track-changes или OVERLEAF_IS_SERVER_PRO=true для Git и полной истории проекта?

Ответ: Нет. В Ayakaleaf Pro нет сервиса track-changes. История проектов хранится сервисами project-history и history-v1, которые всегда работают внутри контейнера sharelatex. Git-bridge читает историю из history-v1 по адресу V1_HISTORY_URL (http://sharelatex:3100/api), который задаёт Toolkit. Не задавайте OVERLEAF_IS_SERVER_PRO: от неё не зависит ни одна функция, она лишь переключает миграции базы данных, выполняемые при запуске, на набор Server Pro.