Memorizzare le dipendenze nella cache per build più rapide

La maggior parte del tempo della CI viene impiegata per scaricare e installare le stesse dipendenze a ogni esecuzione. La memorizzazione nella cache le conserva tra un'esecuzione e l'altra, così le build successive riutilizzano il lavoro già svolto, riducendo spesso drasticamente la durata della pipeline.

GitHub fornisce actions/cache. È necessario indicare un percorso da memorizzare nella cache e una chiave che identifichi la voce della cache. In caso di hit, il percorso viene ripristinato; altrimenti viene salvato al termine del job.

La chiave dovrebbe cambiare solo quando deve cambiare anche il contenuto memorizzato nella cache. L'ideale è calcolare l'hash del lockfile: un nuovo lockfile indica nuove dipendenze, quindi viene creata una nuova voce della cache.

restore-keys fornisce prefissi di fallback. Se non viene trovata una corrispondenza esatta, l'action ripristina la cache più recente la cui chiave inizia con un prefisso, offrendo un avvio parzialmente già preparato.

In caso di corrispondenza esatta della chiave si verifica un cache hit e il percorso viene ripristinato. In caso di miss, il job viene eseguito normalmente e la cache viene salvata al termine utilizzando la chiave primaria, pronta per la volta successiva.

Le action di configurazione dei linguaggi includono già il caching. Per Node, setup-node con cache: npm gestisce la cache delle dipendenze, senza bisogno di uno step di caching separato.

Memorizzi nella cache le directory di download del gestore dei pacchetti, non la directory node_modules già installata, quando possibile, perché le cache dei download sono portabili e lo step di installazione verifica comunque l'integrità.

• Node: ~/.npm
• Python: cache di pip
• Java: ~/.m2 o le cache di Gradle

Le cache hanno come ambito un branch, con fallback al branch predefinito, e un limite di dimensione per repository. Le cache inutilizzate vengono eliminate nel tempo; progetti quindi chiavi che possano cambiare senza problemi.

Se la chiave non cambia mai, è possibile fornire dipendenze obsolete. Colleghi sempre la chiave all'hash del lockfile, così gli aggiornamenti invalideranno automaticamente la cache.

Nelle build a matrice su sistemi operativi o versioni diverse, includa runner.os e la versione nella chiave, così ogni variante avrà la propria cache corretta senza conflitti.

Confronti la durata dei job prima e dopo l'introduzione della cache e osservi nei log l'indicatore di cache hit. Un tasso di hit costantemente basso segnala una chiave che cambia troppo spesso.

Verifichi la comprensione della memorizzazione nella cache delle dipendenze.

Ha velocizzato la CI con la memorizzazione nella cache delle dipendenze: l'action actions/cache con una chiave basata sull'hash del lockfile e il fallback restore-keys, il caching integrato nelle action di configurazione, la scelta di cosa memorizzare nella cache, l'inclusione del sistema operativo e della versione nelle chiavi delle build a matrice e la prevenzione delle cache obsolete collegando la chiave al lockfile.