Add 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 Carthage step then that’s all you have to do.
Select the Cache:Push step and specify the following paths for caching (Cache paths input):
./Carthage -> ./Carthage/Cachefile
Make sure that you set bootstrap as the Carthage step’s Carthage command to run input/option, only that command can leverage the cache!
If your Carthage directory is not in the root of your repository then you should specify the path relative to the repository root, e.g. ./subdir/Carthage -> ./subdir/Carthage/Cachefile
That’s all. This specification (using the -> indicator) means that the ./Carthage directory should be cached, and that the cache should be updated only if the ./Carthage/Cachefile file changes.
Note: it’s really important to use bootstrap as the carthage_command, as that’s the only one which can leverage the cache! Running e.g. the update command does not generate the required cache infos, because carthage update will disregard the available files/the cache!
Hi @viktorbenei, why is it important to have the cache push step at the very end of the workflow? Wouldn’t it be enough to place it right after the Carthage step?
If the cache push step is the last one, then cache push will only happen if every other step was successful / if the whole build was successful.
If you put it right after the Carthage step then it’ll push the cache even if e.g. the build fails.
Which one you prefer is up to you, only caching if everything was successful is probably safer, but I don’t think there’s any serious issue with the second option either.
Ah, thanks! That makes sense. In our case it’s usually not the dependencies that make the build fail, so I’ll keep it right after Carthage step, to save some time
Can you please create an issue report for this? Either in #issues:build-issues or via email/the onsite chat on bitrise.io ; to make it easy to track the issue, communicate and notify once done
May I ask why you want to use a custom script instead of our Carthage step?
If the paths are right I believe that should work, but without the logs it’s really hard to tell - if possible I’d suggest you to fill out a #issues:build-issues report, from that we should have enough info
Hi, what if there was a change in the cartfile? Doesn’t bootstrap look only at cartfile.resolved? We had a problem with one of our most recent builds where we had to use update instead to make it fetch dependencies from the updated cartfile.