Quando nei progetti si hanno dipendenze di terze parti (per esempio NuGet package, npm, Yarn, pip, etc.), l'operazione di restore o installazione di queste dipendenze potrebbe richiedere una grande quantità di tempo, che è proporzionale al numero di dipendenze. Questo tempo è ottimizzabile sfruttando la GitHub Action chiamata cache, che può salvare, appunto, una cache delle dipendenze, così che poi non debbano più essere re-installate nell'operazione di restore.

- uses: actions/cache@v1
  with:
    path: ~/.nuget/packages
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
    restore-keys: |
      ${{ runner.os }}-nuget-

- name: Install dependencies
  run: dotnet restore

In questo caso l'esempio è predisposto per .NET, ma sarà similare per gli altri package manager. L'operazione di cache viene eseguita sempre prima del restore e va a salvare, sotto una chiave precisa, tutte le mie dipendenze, nel momento in cui ci sia un cache miss (ovvero la chiave non esiste perchè è la prima esecuzione) e, quindi, l'operazione di restore installerà tutte le dipendenze.

Run actions/cache@v2
Cache not found for input keys: Windows-nuget2-3881b0e254e4b0c4e40edd9efa8c26dfd9f5c93c42dad979f6c5869b765a72d0, Windows-nuget2-

Post Run actions/cache@v2
Cache saved successfully
Post job cleanup.

Nel secondo run della pipeline, ci sarà invece un cache hit (in base al nome della chiave) e, quindi, le dipendenze verranno scaricate e unzippate dallo step di cache, poi, il restore, che dovrebbe fare uso del packages.lock.json, sarà molto più veloce, quasi immediato.

Run actions/cache@v2
Cache Size: ~116 MB (122108071 B)
C:\windows\System32\tar.exe -z -xf d:/a/_temp/50db9096-3e6c-4681-8753-3e12e33854f1/cache.tgz -P -C d:/a/VsShowMissing/VsShowMissing
Cache restored from key: Windows-nuget2-3881b0e254e4b0c4e40edd9efa8c26dfd9f5c93c42dad979f6c5869b765a72d0

L'uso della cache è vantaggioso solo in quei casi in cui ci siano veramente molte dipendenze. D'altronde vengono comunque scaricate tutte e unzippate localmente quindi, quando ci sono poche dipendenze, potrebbe essere che ci troviamo addirittura un overhead in termini temporali rispetto ad una esecuzione senza cache. Quando ce ne sono tante, invece, l'operazione risulterà più veloce perchè la cache sarà tenuta in una location molto vicina a quella della VM che eseguirà il workflow, pertanto l'operazione di download dovrebbe essere più veloce, ma va chiaramente misurato caso per caso per vederne l'efficacia.