Artifact Cache
Accelerate your workflows with the Artifact Cache.
The BuildPulse cache seamlessly replaces GitHub’s cache action, providing faster and more reliable performance. Unlike GitHub's cache, which stores artifacts in Azure Blob Storage and may suffer from latency issues, the BuildPulse cache is co-located with BuildPulse Runners, minimizing network latency.
Usage
Switching from actions/cache to the BuildPulse cache requires replacing the actions/cache@v4 line in your workflows with buildpulse/cache@v7:
name: Cache dependencies
- uses: actions/cache@v4
+ uses: buildpulse/cache@v7
with:
key: ${{ runner.os }}-yarn-${{ hashFiles('./yarn.lock') }}
path: ./node_modules
If you're currently using actions/cache/save or actions/cache/restore, update them to buildpulse/cache/save and buildpulse/cache/restore, respectively.
Refer to the GitHub repository for more technical documentation.
Cache Size and Pricing
Using the BuildPulse cache incurs no additional cost, no storage limits, and has a data retention policy of 14 days.
Credentials
The runner supplies the cache's credentials, so a workflow does not configure anything.
Two things are worth knowing if your workflow also uses AWS for its own purposes:
- The cache does not read
AWS_ACCESS_KEY_IDorAWS_SECRET_ACCESS_KEYfrom your job. Runningaws-actions/configure-aws-credentialsin the same job has no effect on it. - If you want the cache to use credentials you control, pass them explicitly with the
aws-access-key-idandaws-secret-access-keyinputs.
When the cache is not working
A cache miss is normal and appears as an information line. A cache that cannot be reached is reported as an error annotation on the step, naming what went wrong, and sets the cache-error output. By default the job still succeeds without a cache; set on-cache-error: error to fail the step instead.
For language-specific caching, point buildpulse/cache at the directory your package manager already uses for its cache. The caching strategies guide has worked examples.