⚠️ The branch-based caching steps are deprecated and being replaced by key-based caching. Check out our migration guide: [Migrating from branch-based caching to key-based caching](https://devcenter.bitrise.io/en/dependencies-and-caching/branch-based-caching/migrating-from-branch-based-caching-to-key-based-caching.html).
Checks whether cache has to be updated based on the Cache Paths and Ignore Paths inputs.
If it does, the Step creates a new cache archive and uploads it.
It won't update/upload the cache if the cache hasn't changed nor in the case of a pull request unless you change the Step's run_if property.
For caching, you will need the Bitrise.io Cache:Pull Step at the beginning of your Workflow (after the Git Clone Repository Step but before a dependency installer Step) to download the previous cache, if any.
The Bitrise.io Cache:Push Step should be the very last Step in your Workflow.
-> syntax, for example, update/this -> if/this/file/is/updated.
Please note the indicator points to a file and not to a folder.! will get ignored from the cache archive.*, **, /.
The * will replace a path element, the ** will replace part of a path.
To exclude a full directory, simply put a / behind the directory.
Note that you can't ignore a path which results in an invalid cache item.$BITRISE_SOURCE_DIR.file-content-hash or file-mod-time) to detect changes in a directory, file, or in an update indicator file.
If changes are detected, new cache gets generated.true, the Step will print out more detailed logs.true, you can compress the cache archive for faster uploads and downloads, especially useful for node-modules and other huge dependency folders.Ignore paths collected by steps you can set which files or extensions should be ignored by the Step during the build.Cache Upload URL shows the URL where the cache gets uploaded.We recommend you do not cache any dependency manager lock file (for example, package.lock, gemfile.lock, podfile.lock) as it would override the lock file in your repository.
