Cache-pull failure because stack has changed (different stack workflows)

Archive Tooling Issues
1

Hi, I’m running two workflows, one to execute some tests using the faster linux-docker-android stack, and the other to build a React Native (with iOS variant) application on the osx-xcode-11.7.x stack.

I noticed the cache-pull step is skipped when the previews workflow run was on a different stack, so all the cache time-saving is not taken advantage of, which in this case is ~15 minutes.

Some cache-push configuration options allow to set the fingerprint method or compression, but not some kind of prefix for the cache name to include the stack type and avoid invalidation when using different stacks.

This is the cache-pull output when it’s skipped:

+------------------------------------------------------------------------------+
| (3) cache-pull@2                                                             |
+------------------------------------------------------------------------------+
| id: cache-pull                                                               |
| version: 2.1.6                                                               |
| collection: https://github.com/bitrise-io/bitrise-steplib.git                |
| toolkit: go                                                                  |
| time: 2020-09-25T22:30:57Z                                                   |
+------------------------------------------------------------------------------+
|                                                                              |
Config:
- CacheAPIURL: [REDACTED]
- DebugMode: false
- StackID: osx-xcode-11.7.x
- BuildSlug: 8815b0f4b39d850e
Downloading remote cache archive
Checking archive and current stacks
current stack id: osx-xcode-11.7.x
archive stack id: linux-docker-android
Cache was created on stack: linux-docker-android, current stack: osx-xcode-11.7.x
Skipping cache pull, because of the stack has changed
|                                                                              |
+---+---------------------------------------------------------------+----------+
| ✓ | cache-pull@2                                                  | 5.07 sec |
+---+---------------------------------------------------------------+----------+

Is there a way to take advantage of the cache when using different stacks on separate workflows?

1 Like
2

Hi @gc1!

Thanks for raising this question! Unfortunately, it isn’t possible to use the same cache across different stacks.

Cache is invalidated if used on a different stack than the one it was generated on. Cache is also not workflow dependent, only branch and app ID.

It came to our attention that this part of the logic isn’t documented well, so we’re working on updating the DevCenter with this information.

3

Thanks for looking into updating the documentation.

It makes a lot of sense that the cache doesn’t work across different stacks, never the less, it would be of enormous help if the cache step could be stack-aware and save-restore multiple archives, one for each stack.

This would speed up the build process when using multiple stacks at a reduced cost.

2 Likes
4

@bitce Probably a default option for the step, in which it specifies a cache prefix related to the stack name, to allow using it across different stacks.

Or probably options like CircleCI offers, in which the cache name can include the architecture/stack, branch name, file checksums, etc, as part of the name.

gem-cache-v1-{{ arch }}-{{ .Branch }}-{{ checksum "Gemfile.lock" }}

To restore the cache, it does partial or full name matches on the file names.

2 Likes
5

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