I've been working on an application that runs on Heroku for awhile and occasionally I run into a funny issue where my background workers start failing. It's as if the background workers have an old version of the gem, which used to talk to a HTTP API and was switched to hit a HTTPS endpoint. The gem that's causing problems is written by me and is pulled from Github with the following line in my Gemfile:
gem 'stubhub', github: 'Zanfa/stubhub'
From my logs, I can see that I'm getting 403s because it tries to hit the non-HTTPS url (which does not exist in the gem anywhere). However when I open the console with heroku run rails c and run the job from there, it never has the same issue.
I've also tried heroku run bundle list and bundle list to compare if there's a mismatch in versions, but it always reports the current version 0.0.23.
And to make things more interesting, this doesn't always happen. There's only like a 20% chance that it will start hitting the non-https endpoint, and doing heroku restart usually fixes it, but it will pop up again in a couple of pushes.
What you need to remember is that every time you do heroku run you're instantiating your slug into a new dyno, not interacting with your existing dynos. Googling will show different people dealing with Bundler caching issues, like http://artsy.github.io/blog/2013/01/15/debugging-bundler-issues-with-heroku/
My advice is to push a version of your repo with an empty Gemfile (to clear out the cache) and then push your normal repo again.
Related
After upgrading a production application on Heroku to cedar-14, I am running into issues with carrierwave-video-thumbnailer. In particular, I get the error:
ffmpegthumbnailer: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
After looking into this, I found that other people are having issues with libjpeg after upgrading to cedar-14 (for other gems besides ffmpegthumbnailer)
My questions are:
Is there a way to fix this?, or otherwise
How can I revert back to cedar-10?
(I tried heroku stack:set cedar-10 but get the error resource not found)
You only have a limited time left on cedar-10, so you'd do well to try to fix the issue. However, if you need to revert it temporarily, read on.
heroku stack:set cedar doesn't seem to be working anymore, probably because it is a ticking time bomb.
To rollback, you can use the heroku rollback functionality.
First, get the version number of the most recent release before you upgraded.
heroku releases
Then, do:
heroku rollback v65
(using the version you identified from the previous step instead of v65)
Good luck!
My site is currently dead therefore I can't explain how urgent for me this is.
Situation: A few days ago I received an e-mail from Heroku "ACTION REQUIRED: Rails Security Vulnerability " advising me to update rails to version '3.2.11'. After I followed all the steps in the e-mail I tried to open my web site. I was extremely surprised when I saw that I can't open my site. My site is made with RefineryCMS.
Is it possible, using git, to restore my site to the previous point in time when everything was working great?
When I run the site locally I get the following error:
ActiveRecord::RecordNotFound in Refinery::PagesController#home
Couldn't find Refinery::Page with id=torte-za-rodendan
...
app/views/stranice/naslovnica/_favourite_products.html.erb:7:in `_app_views_stranice_naslovnica__favourite_products_html_erb__4156700835010289094_66485000'
app/views/refinery/pages/home.html.erb:16:in `_app_views_refinery_pages_home_html_erb___2482419061129865361_67
Yep, we all got that email from Heroku.
Since your site was versioned with git before, you can undo the last commit by following these steps.
However, I am not sure whether you really need to do the above. You just need to make sure that your heroku app runs on rails 3.2.11 - it is a pretty serious security issue, maybe heroku even blocks sites that aren't upgraded quickly enough.
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.11 in your Gemfile
Change RAILS_GEM_VERSION to '3.2.11' 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
Doing it only on the new branch ensures nothing breaks.
If you still get errors afterwards, please tell us what's in heroku's log.
Is there an issue with developing my site on my macbook and then moving to a server when done? Will there be issues I need to plan ahead for? DB or ruby related maybe? Dependencies or something a server could have different from my dev environment that could cause a nightmare later? I'd rather develop it offline since it'd be faster and wouldn't require an internet connection but in the past I've always done everything with live sites so this would be a first, and I am new to ruby on rails.
Developing locally and then deploying to your server(s) via something like capistrano is standard practise.
It's a good idea to keep your development environment as close as possible to your production environment (ruby versions, database versions etc). Bundler makes keeping your gems in sync easy
I used Heroku for some projects. The deployment was as easy as it could be. I just did a git push and it worked without problems... I really like bundler and rake :-)
Your Question embodies THE way to develop in Rails. Your development environment is an offline representation of what you're production site will be.
A quick workflow analysis for you could be:
rails new ~/my_app -d postgresql; cd ~/my_app; rm public/index.html
Next, create the database:
bundle exec rake db:create:all
Now you'll have the db and app all set up, let's set up your main pages:
bundle exec rails generate controller Site index about_us contact_us
Now you'll have something to see on the site, so run:
bundle exec rails server
This server acts as your offline connection and will handle the rendering of any text, images, html etc you want to serve in your rails app. Now you can join in the debates of TDD, to TATFT or JITT, rspec vs test::unit. Welcome.
Developing locally is definitely the way to go. However, I would look into getting it on production as soon as possible and pushing often. This way you can see changes happen as you make them and are aware of any possible breaking changes.
I use heroku a lot and when I start a new project I push it to heroku almost immediately. While developing, I can publish new changes simply by git push heroku master. Everyone has to find their own workflow, but this has always worked well for me.
If you are interested in Heroku here is a good link to get you started:
https://devcenter.heroku.com/articles/rails3
I'm trying to deploy my rails application with heroku (as shown here). I've created a very simple rails application (using ruby 1.9.2 and rails 3.0.3; i'm sure heroku supports these - see heroku docs), created and pushed github repo, created heroku repo and pushed it (all commiting is done). And when i'm trying to access my application controller, it throws 404 rails page like it's saying 'there is no such controller'. I've done heroku rake db:migrate but first time i ran it i got 'host not found' error. Running this again fixed that. Well, i'm not sure if i should run heroku addons add:postgresql - i though postgres is on by default, but heroku says i should pay in order to get DB (running command i've mentioned asks me to confirm billing it).
May be it sounds stupid, but how can i deploy my rails application (it's a very simple one) without paying any fees and such troubles as 404 pages like i mentioned in the beginning of my post? (and this is my question). Maybe i should choose other hosting (if it exists in our world) or am i doing something wrong with heroku?
You forgot to push your quotes_controller.rb to git and heroku probably.
git add controllers/quotes_controller.rb
it seems you forgot models also, and probably lot of files.
I have a Passenger-based production Rails application which has thousands of users. Occasionally we need to apply a code patch (we use git) and the current process for doing this (you can assume there are no data migrations) is:
Perform git pull origin [production-branch-name] on the server
touch tmp/restart.txt to restart Passenger
This allows us to patch the server without having to resort to putting up a maintenance page, which is great, but it doesn't feel quite right since it's not actually a proper 'deployment', and we still need to manually update the revision file and our deployment doesn't appear in the Hoptoad or NewRelic services we use.
Ideally I would run cap production deploy and just let the standard Capistrano deployment script take care of everything, but is this a dangerous thing to do without putting up a maintenance page? This deployment process seems to be fairly safe in that the new revision is deployed to a completely separate folder and only right at the end of the process is a symlink re-created to switch the currently deployed version, but I'm still fairly paranoid about this somehow resulting in a lost or failed request.
No problems here doing cap production deploy. If the deployment fails then the previous release is still good. Nothing will fail as the old release is loaded (cached) in the current Passenger process. The touch tmp/restart.txt will pick up the new release and all is good in the world.