I have seen a number of questions and answers on how to reduce your Heroku slug size but I can't get it to budge. In How to reduce heroku slug size? it is mentioned that there is a bug in Bundler that means that unused gems are not cleaned out.
One of the comments on that question says:
Note that this issue has now been fixed with Bundler. Opening a support ticket is no longer necessary
I have a few questions:
Does this mean that an updated version of Bundler is now used on the
Heroku Bamboo stack with this fix in it?
Do I have any control over which version of Bundler is being used by Heroku?
Is Heroku running on a newer version of Bundler then the "release" version?
Does this mean that an updated version of Bundler is now used on the Heroku Bamboo stack with this fix in it?
No, as far as I am aware the Bundler has not changed on Bamboo
Do I have any control over which version of Bundler is being used by Heroku?
No
Is Heroku running on a newer version of Bundler then the "release" version?
Sometimes, for instance, at the moment they are running a Bundler rc on Cedar.
For reducing slug size, check the Dev Center article: http://devcenter.heroku.com/articles/slug-size
You may be experiencing the same problem reported in this blog post from a few months ago - http://dazedthots.blogspot.com/2011/07/reducing-slug-size-heroku.html
Related
I need an updated version of bundler on my heroku application (cedar 14) and I haven't seen any reason why I can't do this. I'm stuck at 1.6.6 which is a couple months old and I need the most up to date version.
I need to specify a source: option for one of my gems and the older version of bundler doesn't allow this. Additionally, running heroku run gem update bundler successfully updates but 'heroku run bundle -v' yields 1.6.6.
Why?
You can modify the bundler version used by specifying the Ruby Buildpack on Heroku:
If you see that a different version of Bundler is being used by your
application than is listed in the Ruby Support article, your
application might be configured to use the master branch of the Ruby
buildpack for deployments.
To check which buildpack is configured, use the heroku buildpacks
command:
> heroku buildpacks
> === hidden-temple-25627 Buildpack URL https://github.com/heroku/heroku-buildpack-ruby.git
The example output shows that an unreleased version of the buildpack
is being used. To switch to the supported version, set the buildpack
as follows:
heroku buildpacks:set heroku/ruby Buildpack set. Next release on
hidden-temple-25627 will use heroku/ruby. Run git push heroku master
to create a new release using this buildpack.
You can verify that the new buildpack has been set by typing:
> heroku buildpacks
> === hidden-temple-25627 Buildpack URL heroku/ruby
Another reason your app might not be using the currently supported
Bundler version is if it is configured to deploy using a different
buildpack URL. This will happen if the BUILDPACK_URL config var is
set.
> heroku config:get BUILDPACK_URL BUILDPACK_URL:
> https://github.com/heroku/heroku-buildpack-ruby.git
If you see any value, then you are using a custom buildpack. If this
value is set to a “multi buildpack” such as
https://github.com/heroku/heroku-buildpack-multi then you will need to
check the .buildpacks file to see what buildpacks are used in
deployment. If you are using this method of deployment we recommend
that you instead follow the guidance in the Using Multiple Buildpacks
for an App article.
The officially deployed Ruby buildpack will sometimes lag behind
master for a few days.
Other than that it can not be directly configured:
Why can’t the Bundler version be configured?
Different versions of Bundler have different known bugs and slightly
different behavior. The Bundler version on Heroku is carefully
curated. A balance needs to be struck between supporting new Bundler
features and stability. The work we put into curating the Bundler
version ensures maximum stability, and avoids deprecation and
notification cycles on Bundler as it changes, or as bugs are fixed or
security issues are patched by Heroku.
The Ruby experience on Heroku is provided by the Heroku Ruby
Buildpack. This is the tool that installs a version of Bundler and
runs all the commands needed to get your application set up. The
buildpack relies on publicly exposed internals of Bundler. It is
tested and known to work against the currently specified version of
Bundler. If you were to take a modern buildpack and use it with an
older version of bundler, you would be likely to see unpredictable
results.
https://devcenter.heroku.com/articles/bundler-version
I keep running into the application error on Heroku website after I write git push heroku master. Does this have something to do with this?:
WARNINGS:
Removing 'Gemfile.lock' because it was generated on windows.
Bundler will do a full resolve so native gems are handled properly.
This may result in unexpected gem versions being used in your app.
In rare occasions Bundler may not be able to resolve your dependencies at all.
and if so how do I fix it?
Thanks in advance
Edit: http://gyazo.com/bc40680795ac3d7c7134fcf84d97c4a1
I just tried deploying my app to Heroku. It's been working for quite a while, I am just adding some new features. Once I deployed, I got an "App Crashed" error. heroku logs showed No such file to load -- nokogiri (LoadError).
Now, on my system, my Gemfile.lock showed 2 different nokogiri gems: nokogiri (~> 1.5.0), a dependency of fog (1.4.0) and nokogiri (1.5.5-x86-mingw32) which doesn't appear to be a dependency of anything. Under platforms was only x86-mingw32. My development computer is Windows 7 with ruby 1.9.3p194 and the Ruby version that the Heroku toolbalt uses for itself is heroku-toolbelt/2.30.1 (i386-mingw32) ruby/1.9.2.
My version of Bundler was up to date, my version of the Heroku toolbelt was up to date. I tried deleting Gemfile.lock and re-deploying on the advice of some forum posts, but the app was still crashed.
It appears that Heroku was simply not bundling in the right version of nokogiri, but was ignoring it on account of my use of Windows. The way I got to to be fixed was I added gem 'nokogiri', '~> 1.5.5' to my gemfile (even though my app does not explicitly need nokogiri, it is only a dependency) and then re-deployed to Heroku without running bundle install on my own system first. Now the app does not crash.
I have no idea why this worked. I don't know how to ensure the problem doesn't occur again, I just happened to get lucky with a desperate patch. I can't have this downtime in the future, or worry about something like this happening again for a routine deploy. Can someone please explain what was actually wrong and the right way to solve it?
Add this
PLATFORMS
x86-mingw32
to your Gemfile. Heroku will then ignore your Gemfile.lock because windows has crazy different dependencies.
I know that my local machine and Heroku are using the same version of the gem, but I'm wondering if it's possible that Heroku hasn't grabbed the latest bug fix tracked here.
Is it possible that my local machine has a newer delayed_job 3.0.0 gem than Heroku does? The fix was committed on the 12th.
When does Heroku update its gems?
This seems likely because I can send email from my local rails app, but on Heroku, I run into problems detailed in the link above. I'm on the bamboo-mri-1.9.2 stack btw.
It short, it doesn't. If you're using Bundler you're stipulating which versions are used in your Gemfile (which in turn defines version numbers in your Gemfile.lock, both of which should be committed to Git).
If you're not using Bundler, and are still using the .gems file at the root of your project, Heroku will use the most recent it has, unless you define a different version in which case it will use that.
More info can be found here: http://devcenter.heroku.com/articles/gems
You should be able to specify a git repository in your Gemfile.
e.g.,
gem "delayed_job", :git => "git://github.com/collectiveidea/delayed_job.git", :ref => "80ca31f9eb"
using the commit with the fix.
(edit: wrong git repo, whoops.)
I have a rails application that I deploy on Heroku. I'm using several different machines, and I noticed that when I add new dependencies (so that Gemfile.lock is rebuilt) and do bundle install on my Windows computer at home, push to Heroku fails with the following error:
Unresolved dependencies detected; Installing...
Windows Gemfile.lock detected, ignoring it.
You have modified your Gemfile in development but did not check
the resulting snapshot (Gemfile.lock) into version control
...
Gemfile.lock IS under version control, but Heroku appearently chooses to ignore it since it's created in Windows, and then complains that it's missing seconds later. Why does this happen? And how can I solve it?
I fixed mine by opening Gemfile.lock and deleting the following two lines:
PLATFORMS
x86-mingw32
So now i just need to make a script that bundles then removes that from the lock file.
Like matt commented above:
The problem is that Bundler creates different Gemfile.locks for Windows. The only solution is to create and commit the lock file on a *NIX system.
I would suggest to create a virtual machine running e.g. Ubuntu – maybe using Virtual Box. You can even get ready-to-use virtual machines – for example here.
From the Heroku Docs:
If the platforms section of your Gemfile contains Windows entries,
such as mswin or mingw, then the Gemfile.lock file will be ignored.
Just battled through this problem for a while.
I trimmed my gemfile back to just rails and still had the issue. Then, thinking that heroku had demanded an update of the heroku gem today, I looked closer at heroku changes.
It seems the 1.9.2 ruby "bamboo" stack is now the default one - my app is still running on the 1.8.7 stack. So I ran "heroku stack:migrate bamboo-mri-1.9.2" and updated the stack to 1.9.2 - not something I wanted to do, but you know what, it fixed the issue above.
Of course, I didn't want to be on the 1.9.2 stack, so I migrated back down to the 1.8.7 stack, and things installed correctly again. So I think this is a workaround - and probably an overly complex one - but it seemed to "flush" whatever the error was heroku-side. As nothing I did locally (and I tried a LOT of things from StackOverflow articles) had any effect, the push just kept failing as above.
So yeah, this fixes it. Doesn't take too long either. But suspect a better workaround may be spotted by more heroku-knowledgeable developers !
Make sure you commit the changes to Gemfile.lock after installing the bundle. On your next push to Heroku, the new gems should be installed correctly.