Linee guida di sviluppo

Linee guida per contribuire a overleaf-pro, con i vincoli di sincronizzazione del repository, le convenzioni sui branch e domande frequenti su upstream e versioni.

​

Introduzione

Prima di immergerti nello sviluppo, ci auguriamo che tu comprenda i seguenti aspetti:

• Ufficialmente Overleaf viene sviluppato in un repository interno, mentre la community edition è pubblicata in overleaf/overleaf. Un copybot si occupa di sincronizzare il codice tra il repository interno e quello pubblico.
• Ayaka-notes/overleaf-pro è un fork della community edition di Overleaf. Speriamo che questo progetto possa durare a lungo, quindi ti chiediamo di seguire le regole prima di contribuire.

​

Regole per i commit

• Non apportare modifiche estese al codice Overleaf esistente. Concentra il più possibile le funzionalità nella cartella services/web/modules. Questo ridurrà al minimo il nostro carico di lavoro quando in seguito dovremo unire e aggiornare il codice.
• Il vibe coding è davvero un approccio molto comodo, ma può facilmente creare disordine nel progetto, rendendolo in seguito impossibile da mantenere: usalo quindi con cautela.
• Non aggiungere contenuti relativi alle traduzioni durante lo sviluppo; usa le traduzioni esistenti ogni volta che è possibile.
• Evita di introdurre variabili d’ambiente se non strettamente necessario. Se servono, assicurati che siano il più possibile coerenti con quelle dell’Overleaf Toolkit o di docs.overleaf.com.

​

Regole per i branch

Per lo sviluppo di overleaf-pro usiamo i seguenti branch:

• main: questo branch viene usato solo per la sincronizzazione del codice upstream, quindi NON eseguire commit di modifiche esterne. In questo branch impostiamo alcuni tag come ce-v[X.x.x], che indicano la corrispondenza con la versione v[X.x.x] della Community Edition ufficiale di Overleaf. Nota: questi tag sono immutabili!
• server-pro: questo è il branch predefinito per lo sviluppo quotidiano.
• feature-X: questo branch viene usato per sviluppare una funzionalità specifica.
• release-vX.0.0: il branch dedicato al rilascio, in cui applichiamo eventuali hotfix prima della release.

Regole dei branch per Overleaf Pro

​

GitHub Action

GitHub Action si occupa della CI/CD automatica, che comprende:

• Aggiornamento notturno del branch main
• Build dell’immagine Docker per lo sviluppo
• Rilascio dell’immagine Docker

​

Domande e risposte

Come trovare l'hash del commit per Overleaf Community Edition X.0.0?

Prima di tutto devi scaricare l’immagine Docker ed eseguire il seguente comando per ispezionarne le etichette:

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"}

Poi puoi verificare se il commit (b0d05c0) è presente nel branch master upstream.

Perché l'hash del commit è lo stesso nelle immagini CE 6.0.0 e 6.0.1?

È un comportamento previsto. La release 6.0.1 è una patch minore costruita sopra l’immagine 6.0.0. Le modifiche vengono applicate applicando patch all’immagine 6.0.0 esistente, anziché ricostruire l’immagine da un nuovo commit. Per questo l’hash del commit all’interno dell’immagine è identico tra 6.0.0 e 6.0.1.

Per informazioni dettagliate, consulta hotfix.