On PR, tell cache pull to use $base branch cache file if it exists

I have an idea that I think could speed up my PR builds and would like to know if it’s currently possible to implement this idea.

So, the idea itself is the following, when doing a PR build, I would like to tell the cache pull step to pull the cache from the ‘$base’ branch the PR is to be put on and disable the cache push step.

Is something currently feasible on the current step mode and the cache pull step somehow? I know the ‘$branch’ thing is available, so I think remaining things to know are:

  • Is cache pull configurable to pick which branch to pull data from? (I think no in my ready of step options).
  • How to conditionally change an input of a step based on a Go template evaluation? (Environment variable I would guess).

The reasoning here is that lots of PR do not change the actual dependencies. As such, starting with a pre-built cache that with high chance will be in “perfect” state would decrease the build time need to run PR.

Any insights in this? Maybe somehow already implemented something like? Or maybe cache pull is already working like this and I need to do (almost) nothing? (That would me awesome :sunny:).

I might have missed something, but I believe this is exactly how the default setup works, the way you described it.

A PR build can pull the cache it just can’t push to prevent it to overwrite the cache.

Why do you think your PR builds can’t pull the cache? Did you have such an error @mvachon? :thinking:

Hi Viktor,

I wasn’t probably clear enough (or misexplained), let’s try to fix that :slightly_smiling_face:

Here the Cache Pull output for a PR branch feature/test that is going to be merged on branch develop:

Switching to workflow: _cache_pull
| (0) Pull cache                                                               |
| id: cache-pull                                                               |
| version: 2.0.1                                                               |
| collection: https://github.com/bitrise-io/bitrise-steplib.git                |
| toolkit: go                                                                  |
| time: 2018-07-03T11:37:26-07:00                                              |
|                                                                              |
2018/07/03 11:37:28 Cache pull...
2018/07/03 11:37:29 Failed to get download url, error: Build cache not found. Probably cache not initialised yet (first cache push initialises the cache), nothing to worry about ;)
WARN[11:37:29] Step (Pull cache) failed, but was marked as skippable 
|                                                                              |
| ! | Pull cache (exit code: 1)                                     | 4.96 sec |
| Issue tracker: https://github.com/bitrise-steplib/steps-cache-pull/issues    |
| Source: https://github.com/bitrise-steplib/steps-cache-pull.git              |

The cache cannot pull because it (what I think) is trying to download a cache artifact for the PR branch. This is correct of course, but I would like to improve the speed of PR.

My idea here is that (the actual flag to enable or the idea being the default is unknown): I would like on PR that the cache of develop branch would be used.

In majority of cases, the develop branch would be stable and recent enough that the cache of it can be used. I would then simply do not_if: .IsPR on my cache push to speed up PR build a bit more.

Hope this was clearer, if there is already a way to do that, I’m all in!


Makes sense and that’s how it should work.

I guess there might be one thing you want to change: on the Settings tab of the app make sure to pick the right DEFAULT BRANCH. As explained in the Cache docs ( https://devcenter.bitrise.io/caching/about-caching/ ) if a branch doesn’t have a cache yet it’ll use the default branch’s cache if that exists.

Let me know if you’d have any questions! :slight_smile:

@viktorbenei That’s probably the exact problem, we use a different default branch and that explains it. I will try that, thanks!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.