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 bitrise.io, or this was a Pull Request build.
This is by design, as outside of bitrise.io 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.
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.
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!
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.
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: