Directives de développement

Directives de contribution pour overleaf-pro, couvrant les contraintes de synchronisation du dépôt, les conventions de branches et les questions fréquentes sur l’amont et le versionnage.

​

Introduction

Avant de vous lancer dans le développement, nous espérons que vous comprendrez les points suivants :

• Overleaf est officiellement développé dans un dépôt interne, et l’édition communautaire est publiée dans overleaf/overleaf. Un copybot est chargé de synchroniser le code entre les dépôts interne et public.
• Ayaka-notes/overleaf-pro est une version dérivée (fork) de l’édition communautaire d’Overleaf. Nous souhaitons que ce projet s’inscrive dans la durée : merci donc de respecter les règles ci-dessous avant de contribuer.

​

Règles de commit

• Veuillez ne pas modifier en profondeur le code existant d’Overleaf. Concentrez autant que possible les fonctionnalités dans le dossier services/web/modules. Cela réduira au minimum notre charge de travail lors des fusions et des mises à jour ultérieures du code.
• Le « vibe coding » est certes une méthode très facile, mais il peut aisément semer le désordre dans notre projet et le rendre impossible à maintenir par la suite ; utilisez-le donc avec prudence.
• Veuillez ne pas ajouter de contenu lié aux traductions pendant le développement ; utilisez autant que possible les traductions existantes.
• Évitez d’introduire des variables d’environnement, sauf en cas de nécessité absolue. Si c’est indispensable, veillez à ce qu’elles soient aussi cohérentes que possible avec celles de l’Overleaf Toolkit ou de docs.overleaf.com.

​

Règles de branches

Nous utilisons les branches suivantes pour le développement d’overleaf-pro :

• main : cette branche sert uniquement à synchroniser le code amont ; veuillez NE PAS y commiter de modifications externes. Sur cette branche, nous posons des tags tels que ce-v[X.x.x], qui indiquent la correspondance avec la version v[X.x.x] de l’édition communautaire officielle d’Overleaf. Remarque : ces tags sont immuables !
• server-pro : branche par défaut pour le développement quotidien.
• feature-X : branche utilisée pour développer une fonctionnalité spécifique.
• release-vX.0.0 : branche dédiée à une version ; nous y appliquons des correctifs à chaud avant la publication.

Règles de branches pour Overleaf Pro

​

GitHub Action

GitHub Action assure le CI/CD automatique, qui comprend :

• La mise à jour nocturne de la branche main
• La construction de l’image Docker de développement
• La publication de l’image Docker

​

Questions/réponses

Comment trouver le hash de commit de l'édition communautaire d'Overleaf X.0.0 ?

Tout d’abord, vous devez récupérer l’image Docker et exécuter la commande suivante pour inspecter les labels de cette image :

bash

docker inspect --format='{{json .Config.Labels}}' sharelatex/sharelatex:6.0.0
{"com.overleaf.ce.revision":"b0d05c0cf0750714e1f467d20ed6c5f5e9467e8f","org.opencontainers.image.ref.name":"ubuntu","org.opencontainers.image.version":"24.04"}

Vous pouvez ensuite vérifier si le commit (b0d05c0) est présent dans la branche master amont.

Pourquoi le hash de commit est-il identique dans l'image CE entre 6.0.0 et 6.0.1 ?

C’est un comportement attendu. La version 6.0.1 est un correctif mineur construit sur l’image 6.0.0. Les modifications sont appliquées en corrigeant l’image 6.0.0 existante, au lieu de reconstruire l’image à partir d’un nouveau commit. Par conséquent, le hash de commit contenu dans l’image est identique entre 6.0.0 et 6.0.1.

Pour plus de détails, consultez hotfix.