Intégration Git

Permettez aux utilisateurs de cloner, récupérer (pull) et pousser (push) leurs projets avec Git via le git-bridge.

L’intégration Git est actuellement disponible sur ayaka-notes/overleaf.

Cette fonctionnalité a été initialement développée par ayaka-notes/ayakaleaf-pro.

1. Activer le git-bridge (utilisateurs du Toolkit uniquement)

   Si vous utilisez le Toolkit, activez le git-bridge en définissant ce qui suit dans votre config/overleaf.rc :

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   Le Toolkit l’ignore sauf si SERVER_PRO=true est également défini. Rien d’autre n’est nécessaire : le Toolkit définit lui-même GIT_BRIDGE_HOST, GIT_BRIDGE_PORT et V1_HISTORY_URL pour le conteneur sharelatex ; ignorez donc les deux étapes Docker Compose ci-dessous. Exécutez bin/up pour recréer les conteneurs.

2. Ajouter le conteneur git-bridge (utilisateurs de Docker Compose uniquement)

   Si vous utilisez un docker-compose.yml personnalisé, ajoutez la configuration de conteneur suivante à votre fichier 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"]
   

   Utilisez le même tag que l’image sharelatex. Le serveur MCP (v6.3.1 et ultérieures) fait partie de l’image sharelatex et est activé en même temps que l’intégration Git ; il ne nécessite donc aucun conteneur supplémentaire.

3. Mettre à jour la configuration du conteneur sharelatex

   Vous devrez également lier le conteneur git-bridge dans le conteneur sharelatex et définir les variables d’environnement suivantes ; faites particulièrement attention à 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. Authentification

   Pour authentifier un client git, les utilisateurs ont besoin d’un jeton d’accès personnel. Les utilisateurs peuvent gérer leurs jetons d’accès personnels depuis l’interface de l’application (voir la documentation) :

   

   Jeton d'accès personnel pour l'intégration Git

5. Surveillance et ressources

   Nous vous recommandons de surveiller les ressources de votre hôte après avoir activé le git-bridge. L’augmentation de la charge dépendra :

   • du nombre d’utilisateurs accédant à la fonctionnalité
   • des types de projets hébergés sur votre instance (les projets plus volumineux sont généralement plus gourmands en ressources)

​

Déplacement des projets vers S3

L’intégration Git stocke sur le disque un dépôt git complet pour chaque projet cloné par un utilisateur. Si votre espace disque est limité, vous pouvez activer une tâche de swap qui déplacera les dépôts les moins utilisés vers AWS S3. Si un dépôt déplacé est de nouveau nécessaire, il est rapatrié sur le disque. Les variables d’environnement suivantes contrôlent la tâche de swap :

Nom	Description
GIT_BRIDGE_SWAPSTORE_TYPE	Définissez cette valeur sur “s3” pour activer la tâche de swap.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Votre clé d’accès AWS
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Votre secret AWS
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Ce bucket contiendra les dépôts git compressés (zip)
GIT_BRIDGE_SWAPSTORE_AWS_REGION	La région du bucket
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Nombre minimal de projets à conserver sur le disque. - Par défaut : 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Seuil bas du swap. La tâche de swap déplacera des projets jusqu’à ce que l’utilisation du disque passe sous cette valeur. - Par défaut : 128 Go
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Seuil haut du swap. La tâche de swap commencera lorsque l’utilisation du disque atteindra cette valeur. - Par défaut : 256 Go
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	Intervalle entre deux vérifications de l’utilisation du disque et exécutions de la tâche de swap. - Par défaut : 3600000 ms = 1 heure

​

Questions-réponses

Si je partage mon projet avec quelqu'un d'autre, comment fonctionne le modèle de permissions du Git Bridge ?

Les utilisateurs disposant d’un accès en lecture seule peuvent uniquement cloner le projet ; les utilisateurs disposant d’un accès en lecture-écriture peuvent cloner et pousser des modifications. Remarque : les utilisateurs doivent être connectés pour rejoindre ce projet.

Comment cloner un projet, et quels nom d'utilisateur et mot de passe utiliser ?

Dans l’éditeur, ouvrez Integrations dans la barre latérale gauche et cliquez sur Git integration. La commande de clonage s’affiche, sous la forme :

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

Lorsque Git demande des identifiants, saisissez git comme nom d’utilisateur et un Personal Access Token comme mot de passe. Générez le jeton dans Account Settings ; il est valable un an. Le mot de passe de votre compte ne fonctionne pas.

Les modifications ne sont pas synchronisées automatiquement : utilisez git pull pour récupérer les modifications faites dans l’éditeur et git push pour envoyer les vôtres. Le chemin /git est servi par le conteneur sharelatex ; un reverse proxy placé devant ne nécessite donc aucune règle supplémentaire.

git push échoue avec HTTP 413 ou curl 55 Broken pipe

Le push dépasse la limite de taille de téléversement, définie par MAX_UPLOAD_SIZE (en mégaoctets, 50 par défaut), qui s’applique également aux pushs. Augmentez-la dans config/variables.env, par exemple MAX_UPLOAD_SIZE=200, puis exécutez bin/up -d. Si vous utilisez le proxy TLS ou votre propre reverse proxy, augmentez également son client_max_body_size (50M dans le fichier config/nginx/nginx.conf du Toolkit).

Le git-bridge refuse également les fichiers de plus de 50 Mo et les projets de plus de 2 000 fichiers. Ces limites sont définies par GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (en octets) et GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM dans config/variables.env.

Le journal du git-bridge affiche Failed to fetch log level

Cet avertissement est sans danger, et le clonage, le pull et le push continuent de fonctionner. En 6.2.x, le git-bridge interroge le serveur de métadonnées de Google Cloud (metadata.google.internal) une fois par minute pour obtenir un niveau de journalisation, ce qui ne fonctionne que sur Google Cloud. Ailleurs, la requête échoue : le git-bridge journalise l’erreur (par exemple null ou un statut HTTP) et conserve le niveau défini par GIT_BRIDGE_LOG_LEVEL. À partir de la 6.3.0, cette vérification est désactivée, et la mise à niveau met également à jour l’image du git-bridge, dont la version suit celle de l’image principale.

Ai-je besoin du service track-changes ou de OVERLEAF_IS_SERVER_PRO=true pour Git et l'historique complet des projets ?

Réponse : Non. Ayakaleaf Pro n’a pas de service track-changes. L’historique des projets est conservé par les services project-history et history-v1, qui s’exécutent toujours dans le conteneur sharelatex. Le git-bridge lit l’historique depuis history-v1 à l’adresse V1_HISTORY_URL (http://sharelatex:3100/api), que le Toolkit définit. Ne définissez pas OVERLEAF_IS_SERVER_PRO : aucune fonctionnalité n’en dépend, elle bascule seulement les migrations de base de données exécutées au démarrage vers celles de Server Pro.