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.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Utilizzare la session affinity con Azure Container Apps
Utilizzare la libreria Benchmark.NET per misurare le performance
Effettuare lo stream della risposta in ASP.NET Core tramite IAsyncEnumerable
Generare token per autenicarsi sulle API di GitHub
Installare le Web App site extension tramite una pipeline di Azure DevOps
Gestire undefined e partial nelle reactive forms di Angular
Gestire liste di tipi semplici con Entity Framework Core
Disabilitare automaticamente un workflow di GitHub (parte 2)
Paginare i risultati con QuickGrid in Blazor
Utilizzare i primary constructor in C#
I più letti di oggi
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- Utilizzare il trigger SQL con le Azure Function
- Disabilitare automaticamente un workflow di GitHub (parte 2)
- Ottimizzazione dei block template in Angular 17
- Paginare i risultati con QuickGrid in Blazor
- Ed infine anche il calendario :)
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!