Caching and faster artifacts in Azure Pipelines
I’m excited to announce the public previews of pipeline caching and pipeline artifacts in Azure Pipelines. Together, these technologies can make every run of your pipeline faster by accelerating the transfer of artifacts between jobs and stages, and by caching the results of common operations like package restores.
Pipeline caching introduces a new
CacheBeta task that takes a path of files to cache and a cache key. A cache key can be the contents of a file (like a package lockfile), a string of your choice, or a combination of both.
For example, to cache Node.js dependencies installed with Yarn:
steps: - task: NodeTool@0 inputs: versionSpec: '10.x' displayName: 'Install Node.js 10.x' - task: CacheBeta@0 inputs: key: | $(Agent.OS) $(Build.SourcesDirectory)/yarn.lock path: $(Pipeline.Workspace)/.cache/yarn displayName: 'Cache yarn' - script: yarn install
As we’ve implemented pipeline caching, we’ve learned that every tool behaves differently. So, we’re excited to release this preview and see the cache used in the wild. If you try out the cache and find it doesn’t improve the performance of the step you’re caching, we’d like to hear about it as an issue on azure-pipelines-tasks. If you can create a public repo and pipeline that we can fork to reproduce your issue, all the better. We’ll be listening to these issues and tuning the cache.
There’s a possibility we’ll make breaking changes between v0 and v1 of the task, so we recommend not yet including the cache in production/master branch CI builds.
Learn more about pipeline caching on docs.microsoft.com.
Pipeline artifacts are the built-in way to move files between jobs and stages of your pipeline and to save files from your pipeline for later use. Pipeline artifacts intelligently deduplicate content and only upload net-new content to the server, which helps speed up repeated builds of the same repository.
To use Pipeline artifacts, just use the
download YAML shortcuts, like this:
steps: - publish: bin artifact: binaries
By default, all artifacts published by previous jobs are downloaded at the beginning of subsequent jobs, so it’s not necessary to add a download step. If you want to control this behavior, use the download shortcut, like this:
steps: - download: none
For most common use cases, the
download shortcuts are recommended. However, if you need more control over how your artifacts are downloaded, you can also use the Download Pipeline Artifact and Publish Pipeline Artifact tasks directly.