Pipeline caching is here! This is something that I have been personally waiting for long time and I’m so happy that it is finally in preview.
Azure DevOps pipeline caching enables hosted build agent to cache NPM, Nuget, Yarn and almost any packages that are used during the build. Performance benefits varies based on how many packages are used and how often they are changed.
Configure caching
Pipeline caching is a new build step that is added before the package restore occurs. For example before Nuget package restore step, or before the build step is run.
After the packages are restored, there is a special “post build” build step that is launched automatically after the successful build. This special step will save the packages into cache, so that you don’t have to worry about storing packages into cache.
Restore cache step contains three mandatory settings:
- Display name: Step name in build log
- Key: Composed string that reflects build environment situation
- Path: Folder that is restored / stored into cache
Key is more simpler than it first sounds. Basically key should be almost every time the path to packages file(s). For example with Nuget it should be the packages.config file of one or multiple projects. The Azure DevOps calculates hash from this file and uses that hash as a key to store cached files. So when packages.config changes => we have new “version of packages” that are used in build. We want to store that as new cache.
Path can be anything. You could use this task to cache other things than just NPM or Nuget packages because the Azure DevOps doesn’t care about the content you are caching. For Nugets you should usually use the root folder of solution file + “packages”. You can look into your local computer and find the Nuget packages folder, then use that as relative path in build step.
So when the build runs the restore cache step should display calculated hash and some download details. Don’t worry if you don’t see download duration’s in first time, because cache is saved after first successful build!
So what about performance? I tried caching in decent size of project with 215 packages (1GB). Restore without caching took 1 minute and 28 seconds. Cache restore + restore with cached packages took 45 seconds, so I just optimized 43 seconds away from build time. That is almost 10% of my total build time, just by adding one build step into my build!