Option to not include arch in cache key

[jmanian]

Describe Request

For the install-deps command I'd like to have an option to not include arch in the cache key. This could be done with a include-arch-in-cache-key option, which defaults to true, just like include-branch-in-cache-key.

Motivation

I have a project that was not using this orb but instead manually running bundle install and manually doing the caching. I had RSpec and RuboCop running in downstream jobs in the workflow. The whole thing looked like this:

1. Bundle job
   1. Read cache, preferring a match on Gemfile.lock, falling back to a non-match
   2. Use apt-get to install libmagic, a requirement for one of our gems
   3. bundle install
   4. Write cache
2. RSpec/RuboCop jobs
   1. Read cache, requiring a match on Gemfile.lock, because we know it will be there from the bundle job
   2. bundle install
   3. rspec / rubocop

Originally I was including arch in the cache key, because I saw that in examples. However I had some jobs fail mysteriously, and it turned out the issue was that sometimes the RSpec or RuboCop jobs ran with a different arch than the bundle job earlier in the same workflow. For example, one would use arch1-linux-amd64-6_85 and the other arch1-linux-amd64-6_106. This would lead to an error in the RSpec/RuboCop jobs because:

1. No cache was found, due to different arch
2. bundle install would then try to reinstall all gems from scratch
3. bundle install would fail because libmagic had not been installed

My solution to this problem was to remove arch from our cache keys, thus ensuring that there would always be a cache hit in RSpec/RuboCop. As far as I could tell, there was no issue sharing caches between these randomly different architectures. Everything has been good since then.

Now I'm trying to convert us to this orb, but this orb always includes arch in the cache keys, which will lead to this issue again. I could solve it by always installing libmagic via pre-install-steps, even in the RSpec/RuboCop jobs, but that's just a workaround — when there's no cache hit due to arch it defeats the purpose of caching the bundle in a shared upstream job.

[jmanian]

I looked back at the docs for cache keys, and the description for {{ arch }} is as follows:

Captures OS and CPU (architecture, family, model) information. Useful when caching compiled binaries that depend on OS and CPU architecture, for example, darwin-amd64-6_58 versus linux-amd64-6_62. See supported CPU architectures.

I'm not a bundler or gem expert, but my read of this is that it shouldn't matter if you restore a bundler cache from one architecture into another architecture. Especially in my example above where it's arch1-linux-amd64-6_85 and arch1-linux-amd64-6_106. So that's why I decided to remove arch from the key in my project when I had the issue explained above.

This also makes me think that arch should not be included by default, but that would a larger change so I did not do it in #131.

[vizjerai]

architecture does matter because there are gems that have c libraries that are compiled on install.

[jmanian]

@vizjerai Thanks for the comment, that makes sense. Do you know whether those gems would break if the installation was ported between arch1-linux-amd64-6_85 and arch1-linux-amd64-6_106? I don't know what all those numbers mean, but my assumption is that the different last number is an immaterial difference, and it would be OK to share a bundle cache between these architectures.

I suppose this is a circle issue: Either they need to ensure that all the steps of a workflow run with the same exact arch, or they need to provide a less granular option to key off of, e.g. one that would return arch1-linux-amd64-6 for both of the above architectures.

But absent those solutions from circle, it seems like for my use case the option to not include arch would be useful and better than including.