How to cache CocoaPods dependencies

How To Caching
1

Setup

(If not added already)

  1. Put the Cache:Pull step after the Git Clone and before the CocoaPods Install steps
  2. Put the Cache:Push step to the very end of the Workflow

If you use v1.0 or newer of the Cache steps and the latest CocoaPods Install step then that’s all you have to do.

For older versions please follow these additional steps:

  1. Select the Cache:Push step and specify the following paths for caching (Cache paths input):
    ./Pods -> ./Podfile.lock


_If your Podfile and Pods directory is not in the root of your repository then you should specify the path relative to the repository root, e.g. `./subdir/Pods -> ./subdir/Podfile.lock`_

That's all. This specification (using the `->` indicator) means that the `./Pods` directory should be cached, and that the cache should be updated only if the `./Podfile.lock` file changes.

## Example workflow

example:
steps:

  • git-clone: {}
  • cache-pull: {}
  • cocoapods-install:
  • certificate-and-profile-installer: {}
  • xcode-archive:
  • cache-push:
    inputs:
    • cache_paths: “./Pods → ./Podfile.lock”

__For more information about the Bitrise Build Cache see the [DevCenter](http://devcenter.bitrise.io/caching/about-caching/).__
2 Likes
2

Hi @viktorbenei I’m trying to use the cache push task but it doesn’t work. Podfiles are downloaded on each build.

Below is my cache publish task for a React Native project . Can you check if I’m doing something wrong?

I don’t really understand what the “->” means. Are two cache items? or is that the Pods folder depends on the Podfile.lock file? I’m following the same approach for the yarn modules.

NOTE: The cache pull if before the yarn task and the cache push is the last one as described in the docs.

Thanks in advance

_cache-publish:
    envs:
    - BUILD_ENV: testing
    after_run: []
    steps:
    - cache-push@2.0.5:
        inputs:
        - cache_paths: |-
            $HOME/.gradle
            ./packages/mobile/ios/Pods -> ./packages/mobile/ios/Podfile.lock
            ./node_modules -> ./yarn.lock
            ./packages/backoffice/node_modules -> ./yarn.lock
            ./packages/backend/node_modules -> ./yarn.lock
            ./packages/web/node_modules -> ./yarn.lock
            ./packages/loadtest/node_modules -> ./yarn.lock
            ./packages/core/node_modules -> ./yarn.lock
            ./packages/mobile/node_modules -> ./yarn.lock
        - ignore_check_on_paths: |-
            $HOME/.gradle/caches/*.lock
            $HOME/.gradle/caches/*.bin
            ./.gradle/*.lock
            ./.gradle/*.bin
3

just found the “->” explanation in the workflow editor by clicking the “Change” button and got it working

You can also specify an “update indicator file” with the → syntax: update/this → if/this/file/is/updated. The indicator can only be a file!

If you have a path in the list which doesn’t exist that will not cause this Step to fail. It’ll be logged but the Step will try to gather as many specified & valid paths as it can, and just print warning about the invalid items.

Thanks!

1 Like
4

That’s right @jpgarcia, we should update the DevCenter to include this - I think right now it’s only explained in the step’s description. That said… it’s actually a step related thing, the caching API supports any cache artifact file - you can even write your own cache steps, it’s just a file storage API on the backend side :wink: The -> syntax is purely a step defined convention.