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.)
Related
When I'm using git push heroku master, I'm facing the issue as shown in the below figure:
Please help me in resolving the issue.
With your log error, your ruby is not supported by Heroku. Check Heroku document then upgrade your Ruby version here
As mentioned in the heroku error logs, your ruby version is not upto date.
In your Gemfile, add this line to the top.
ruby '2.5.3'
run bundle install, commit and push again to heroku.
Its always good practice to specify your ruby version for all your project. This is good when you are moving your project from one environment or different server.
Add ruby '2.5.3' in your Gemfile as top most line and bundle
My understanding is that the gemfile in a Rails app only provides references to the actual code of these gems on your local computer. So when you're running your app locally, it's pulling the gem code from your local computer. What happens when you deploy though? The server runs your rails code, but does it also hold all the references in your gem file and automatically download them as well?
Yep. If you deploy on Heroku, you can see bundler doing its work and pulling down the gems.
As per the Bundler docs, you can use bundle show --paths to see exactly where your gems are being loaded from.
Additionally, if you aren't using bundler, you can use the command gem environment to see gem paths on the system.
See this existing answer for more info: How can I find where gem files are installed?
Of course you all heard about the latest security hole in Rails which requires some updates. I'm currently using version 2.3.14 of Rails and therefore tried updating to 2.3.15 (the patched version).
On my local machine the process really went the rails way. But after pushing the changes to Heroku and waiting for deployment, my app didn't start. It says in the logs
RubyGem version error: rails(2.3.15 not = 2.3.14)
No how could that happen? My Gemfile says
gem 'rails', '~> 2.3.15'
and my Gemfile.lock says
GEM
specs:
rails (2.3.15)
and, finally, Heroku tells me
Installing rails (2.3.15)
Really, where is the problem? Other people having this problem?
Solution
The answer by Charles included the solution, which is to update the RAILS_GEM_VERSION to 2.3.15 in config/environment.rb.
Important Notice
If you have the same troubles, please use one of the proposed solutions immediatly. There are already known cases of corrupted Rails apps!
It seems like you also need to do change RAILS_GEM_VERSION to 3.2.15 in environment.rb:
If you find yourself having to do the whole upgrading process over again, you can follow these steps:
Run your tests and make sure everything works
Open up a new branch through git (git checkout -b new_rails)
Change Rails 3.2.15 in your Gemfile
Change RAILS_GEM_VERSION to '3.2.15' in environment.rb
Run bundle update rails
Run the tests and see if everything still works
If not, reverse back to the old branch by doing git checkout master; optionally delete the new branch by doing git branch -D new_rails
Taken from this question:
Site dead. "ACTION REQUIRED: Rails Security Vulnerability "
I have a RoR server that I am decommissioning and need to move the existing Rails apps to a new server. The Rails apps are running Rails 2.3.5 and RubyGems 2.3.5.
The problem I am having is that some of the Gems do not seem to be available anymore - one example is thoughtbot-paperclip --version=2.3.1
I need to install these gems in order for the apps to work on the new server.
Would these gems have been removed from the remote repos? And if so how can I transfer them to the new server? I have tried just copying the entire gems folder from one server to the other but this does not seem to work.
Most of the old gems got renamed, as they usually were in a github_username-gem_name format. But after GitHub stopped hosting gems and gemcutter.org came, they got renamed to only the gem_name, such as thoughtbot-paperclip to just paperclip.
You might get away with just specifying the version number in a Gemfile, such as
gem 'paperclip', '2.3.1'
Looks like the gem has been renamed to simply paperclip. Check the repository.
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.