Hacker News new | ask | show | jobs
by byroot 1908 days ago
Or you know... just cache them.

If your CI or deploys broke because of this, it basically means you're constantly re-installing all your dependencies from scratch, which is totally silly.

Configure your CI & other tools to cache the bundler directory between builds and not only you'll be protected from this, you'll also make your systems faster.

2 comments

There can be other wrinkles. Builds of $dayjob's Rails app failed even though we had the gem itself cached locally all over, because entries for the BSD gem versions had vanished from the rubygems.org metadata, and we weren't caching that. There are multiple workarounds, but we may not be done debating them before rails-core decides on a replacement.
What's even more silly is implying that caching your dependencies is some kind of a fix here. So you'll be able to deploy for a few more days, then what?
Then the 0.3.6 version was released, and we could update because the license isn't much of a problem in this case.

Alternatively we could have continuee to deploy for a few more days until Rails core shipped a new version of Active Storage without that dependency.

It's effectively the same as vendoring, except we're not blowing up our repositories with 10 years of dependencies.

I should clarify... Vendoring is a terrible solution. Caching is a general good practice but not a solution.

All in all, this kind of thing happens once in a blue moon...

I don't claim it's a long term solution, and that you should run of your cache for years.

But having that cache means you have the time to get a clean solution rather than having to rush something because nobody can work anymore can you can't deploy fixes to production either.

These yanking issues are really problematic, but if they interrupted your workflow, then there's something wrong with your build pipeline.

It allows you to deploy for a few more days. That fixes the "i can not deploy problem" if my customer needs a urgent fix.

Sure you will be as much in violation of GPL as without that (even if you don't deploy you will violate the GPL), but that is another problem which needs to be addressed.

> That fixes the "i can not deploy problem" if my customer needs a urgent fix.

Only if the issue is fixed upstream before your cache expires. Obviously, breaking Rails gets things fixed quickly, but what if it was a less-actively-maintained gem?