Stanno andando sempre più di moda i monorepo, ovvero quei repository che contengono al loro interno più progetti, soluzioni, o architetture. Ad esempio, è abbastanza comune per il frontend avere dei monorepo con all'interno più microfrontend, ovvero tanti piccoli servizi che contribuiscono, come funzioni singole, a realizzare il prodotto completo. In alternativa, è comune anche trovare dei monorepo con lo stesso progetto, ma realizzato in più "varianti", come il mobile, il sito web, le API di backend e così via.

Tutti gli approcci possono essere validi, ma è bene ricordarsi che più il repository diventa grande, più tempo ci vorrà per mettere eseguire i nostri workflow. E poiché i workflow non sono mai del tutto gratuiti e, anzi, il pricing è per minuto di esecuzione, se riusciamo a ridurre i tempi, è una buona cosa.

Riprendendo l'ultimo esempio, supponiamo che le tre architetture vengano rilasciate in momenti diversi e che non abbiano tutte lo stesso numero di versione. In questo caso specifico, se dobbiamo rilasciare una nuova versione dell'app mobile, non abbiamo bisogno di scaricare il codice relativo al backend o al client web. Per questo, entra in gioco git.

- uses: actions/checkout@v6
  with:
    fetch-depth: 0
    sparse-checkout: |
      src/common
      src/mobile

Git, infatti, offre la funzionalità dello sparse-checkout e permette di scaricare solo una porzione del repository (che siano file o cartelle poco importa) e tracciare solo quelle. Sui repository molto grandi, questo fa la differenza perché il tempo risparmiato sarà notevole, ma anche in termini di sicurezza non andremo a "sporcare" il runner con file che non riguardano il codice che dobbiamo compilare e portare in produzione.