heroku-buildpack-cacheload

Copy files from cache. Paths are read from .buildcache file in your project source code.

You should use this, if your project is pulling a lot of dependencies during each build. If you store them into cache and during build you just check if they haven't changed, your build time will reduce dramatically.

Usage example

$ heroku config:add BUILDPACK_URL=https://github.com/ddollar/heroku-buildpack-multi.git

.buildpacks:

https://github.com/heroku/heroku-buildpack-nodejs
https://github.com/zakjan/heroku-buildpack-cacheload#1.0.1
https://github.com/kr/heroku-buildpack-inline
https://github.com/zakjan/heroku-buildpack-cachesave#1.0.1

.buildcache:

# Cache dependency directories
code/server/node_modules
code/client/node_modules
code/client/bower_components

# Cache a specific directory (trailing slash is optional)
assets/

# Cache an individual file
config/credentials.json

# Exclude previously listed paths from being cached
!code/client/node_modules

.buildcache Syntax

The .buildcache file supports a .gitignore-like syntax. For performance, inclusion and negation lines are handled differently:

• Inclusion — a literal file or folder path that is added to the restore set, e.g. code/server/node_modules or config/credentials.json. Folders are restored recursively. Glob patterns are not expanded for inclusion lines; list each path you want to restore explicitly. A trailing / (e.g. assets/) is allowed and treated the same as the path without it.
• Negation (!): !path/or/glob — after the inclusion paths are restored, matching paths are removed from the restored files. Negation lines support literal paths (including paths nested inside a restored folder, e.g. !code/client/node_modules/tmp), directories, and glob patterns (*, ?, [...]); a leading **/ matches at any depth, e.g. !**/*.log. Negations only ever remove files that were restored from cache — they never touch other files already present in the build directory. Matching paths are also purged from the cache directory itself, so excluded/old cache files are cleaned up on every build instead of being reloaded each time (this keeps the cache, and therefore the slug, from growing without bound).
• Comments (#): Lines starting with # are ignored.
• Empty lines are ignored.

Listed paths that do not exist in the cache (for example on the first build, before anything has been cached) are silently skipped — they are logged as ✗ - not found and do not fail the build.

Inclusions are restored in parallel to speed up the cache load.

Rails assets:precompile caching

A common use case is caching compiled Rails assets together with heroku-buildpack-cachesave:

public/assets
tmp/cache

# Drop the Sprockets manifest so the Ruby buildpack re-runs assets:precompile
# instead of skipping it when a manifest is present.
!public/assets/*manifest-*.json

Because negations are now purged from the cache directory too, the stale manifest is cleaned up on each build rather than being reloaded every time, which prevents the cache (and the resulting slug) from growing on every deploy.

Troubleshooting

How to clear the cache?

Use heroku-repo plugin.

$ heroku plugins:install https://github.com/heroku/heroku-repo.git
$ heroku repo:purge_cache -a appname