Comment by maccard
1 day ago
> Ye,s but if your CI isn't terrible, you have the dependencies cached, so that subsequent runs are almost instant, and more importantly, you don't have a hard dependency on a third party service.
I’d wager the majority of CI usage fits your bill of “terrible”. No provider provides OOTB caching in my experience, and I’ve worked with multiple in house providers, Jenkins, teamcity, GHA, buildkite.
GHA with the `setup-ruby` action will cache gems.
Buildkite can be used in tons of different ways, but it's common to use it with docker and build a docker image with a layer dedicated to the gems (e.g. COPY Gemfile Gemfile.lock; RUN bundle install), effectively caching dependencies.
> GHA with the `setup-ruby` action will cache gems.
Caching is a great word - it only means what we want it to mean. My experience with GHA default caches is that it’s absolutely dog slow.
> Buildkite can be used in tons of different ways, but it's common to use it with docker and build a docker image with a layer dedicated to the gems (e.g. COPY Gemfile Gemfile.lock; RUN bundle install), effectively caching dependencies.
The only way docker caching works is if you have a persistent host. That’s certainly not most setups. It can be done, but if you have that running in docker doesn’t gain you much at all you’d see the same caching speed up if you just ran it on the host machine directly.
> My experience with GHA default caches is that it’s absolutely dog slow.
For reference, oven-sh/setup-bun opted to install dependencies from scratch over using GHA caching since the latter was somehow slower.
https://github.com/oven-sh/setup-bun/issues/14#issuecomment-...
> My experience with GHA default caches is that it’s absolutely dog slow.
GHA is definitely far from the best, but it works:, e.g 1.4 seconds to restore 27 dependencies https://github.com/redis-rb/redis-client/actions/runs/205191...
> The only way docker caching works is if you have a persistent host.
You can pull the cache when the build host spawns, but yes, if you want to build efficiently, you can't use ephemeral builders.
But overall that discussion isn't very interesting because Buildkite is more a kit to build a CI than a CI, so it's on you to figure out caching.
So I'll just reiterate my main point: a CI system must provide a workable caching mechanism if it want to be both snappy and reliable.
I've worked for over a decade on one of the biggest Rails application in existence, and restoring the 800ish gems from cache was a matter of a handful of seconds. And when rubygems.org had to yank a critical gem for copyright reasons [0], we continued building and shipping without disruption while other companies with bad CIs were all sitting ducks for multiple days.
[0] https://github.com/rails/marcel/issues/23
2 replies →
This is what I came to say. We pre cache dependencies into an approved baseline image. And we cache approved and scanned dependencies locally with Nexus and Lifecycle.