Cache Push is not working since Run-If expression is false(which should not be false)

below is the logs I got.
I have Android and iOS project, but both of them don’t cache and output same log.


| (7) cache-push@2.0.3                                                         |
| id: cache-push                                                               |
| version: 2.0.3                                                               |
| collection:                |
| toolkit: go                                                                  |
| time: 2018-01-12T04:25:39Z                                                   |
|                                                                              |
|                                                                              |
| - | cache-push@2.0.3                                              | 1.03 sec |
WARN[04:25:39] The step's (cache-push@2.0.3) Run-If expression evaluated to false - skipping 
INFO[04:25:39] The Run-If expression was: .IsCI | and (not .IsPR) 

I am sure that the build was PR, but somehow Run-If expression becomes false.

1 Like


The run if expression states why push was not performed, push is only performed for CI builds & are not performed for PR builds.

Based on this you either ran this build locally / not on, or this was a Pull Request build.

This is by design, as outside of you can’t access the Build Cache from the step, and Pull Requests can access the Build Cache (read only) but can’t update it, only after the PR is merged.

If you’d have any questions just let us know! :slight_smile:

Thanks for your quick reply.

Pull Requests can access the Build Cache (read only) but can’t update it, only after the PR is merged.

I see, I missed this.
So if I want to automatically create cache for a specific branch, I need to run a build with push trigger instead of pull request trigger, am I right?

Is this restriction documented somewhere?
I read About caching document, but it seems like there is no comment about this restriction.

1 Like

Well, it’s not a technical restriction just a strongly suggested default behaviour :wink: Meaning: you’re free to change the run_if statement of the Cache:Push from the default run_if: ".IsCI | and (not .IsPR)" ( - you can change this in your bitrise.yml, in YML mode ( e.g. to just run_if: .IsCI (removing the not .IsPR part) but I’d suggest you to not to change it, unless you really need this.

Especially if the repo is a public one, you should never allow pull requests (which in that case can be opened by anyone) to alter anything which can affect other builds (the cache definitely can, by definition).

If you have any questions just let us know!
Happy Building! :slight_smile:

1 Like

hey @viktorbenei, sorry for digging this corpse, but I’m having the same “issue” (it’s not a bug if it’s a feature, but bear with me here…)
I inherited a project that is running PR webhooks on Bitrise, which I’ve been enjoying a lot, but I’m not very familiar with how it works. I’ve been trying to update Carthage dependencies due to a Swift version bump and after like 4 hours not understanding why it wasn’t caching stuff, I found the run_if warning on cache:push step and ended up here.

I understand why I should not cache:push on a PR triggered build, but this workflow is what is webhooked to my Github pull request, approving it or not based on wether tests run successfully or not. If a pull request changes the Cartfile, Carthage will bootstrap the dependency and I’d like to have the Carthage folder cached for the next time a PR is created and I need to decide wether I should clear it for merging or not. I think the problem is I’m probably misunderstanding the .IsCI and .IsPR and how everything is ran inside Bitrise, but I’d appreciate having your input on this.


Hey @eduardo.pinto!

What you describe makes perfect sense, you are free to overwrite this run_if condition at your own will of course. This can be done as simply as this example:

- cache-push@2.2.0: {}
        run_if: true 

This, of course, would result in the step running in each and every case. You might not want that, but you can read all about how these conditions work here:

1 Like