I noticed that when I set my Rails app to production it created a folder in my application called RAILS_ENV=production I've kinda rolled back now and not pushing to production. Am I free to delete this folder?
The "rails" command in Rails 2 creates a new app, while the same in Rails 3 runs script/... so it looks like you've installed an old version of Rails on your production server.
If it's your development machine, this can happen when you have rvm installed with different versions of rails.
I have now fixed this issue, there was a 'PATH' setting in my bundler config file that kept re-creating the folder when I updated my bundle. I removed the path declaration and now it uses the default path.
Related
If I boot Aptana to begin a new rails app, and go to do rails new app, it tells me there is a discrepancy between my ruby version and the ruby version in my gemfile. Which gemfile is that referring to? I haven't been able to initiate the rails new command. Where do I need to change that setting? I am on a Windows machine.
By the way, this issue first arose when I did a git pull for a rails app. Somehow my machine's ruby version was overridden by the ruby version in the gemfile of that app. But even when I change it in the gemfile of that app it still keeps telling me that I'm running a different version of Ruby than is listed in the gemfile. So something is overridden somewhere else. Even when I reboot, restart, use a different root directory, etc, I still run into the same issue.
Having a weird issue and need help.
I am trying to start a rails console on a production server and it is acting like the rails c command does not exist.
FWIW, I have been a rails developer for 4 years and do this all the time on a plethora of other servers without issue. On this server, I can drop, create, migrate, seed the database with no problems (using RAILS_ENV=production), and the app works fine live without any issues.
Setup:
Ubuntu 14.04 (racksapce 2nd gen performance 1 server)
Nginx with Passenger (I typically use Unicorn, but have never had a problem on any of the apps I have deployed with Passenger)
Ruby 2.1.5 (using rvm)
Rails 4.1.7
Postgres
Capistrano 3 (using the rvm, migrations, asset-precompilation, etc. extensions)
What I've tried:
cd into app directory:
cd /home/deployer/app_name/current
Which loads .rvmrc and shows that I am in the correct gemset, ran bundle just for kicks.
rails c production # (which usually works no problem)
bundle exec rails c production # (sometimes have to do this on older apps that do not have the newer capistrano 3 and rvm setup)
rails c production RAILS_ENV=production # (getting desperate here)
RAILS_ENV=production rails c production # (haha, surely this won't work, but out of options)
RAILS_ENV=production bundle exec rails console
Every time, I get a notice that implies 'rails c' is not a valid command:
Usage:
rails new APP_PATH [options]
Options:
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
..... yada yada, shows the rest of the rails options (oddly enough does not show 'c' or 'console' as options?)
Again, I have logged into hundreds of production consoles on both nginx/apache deployed with old and new versions of both Unicorn and mostly older versions of Passenger.
This is the first time I have ever gotten this message, and the console is the ONLY thing that seems to be broken - everything else works fine! the app is live and works great.
I know that the first thing to be suggested is that I am not running rails c production from the app directory - I have cd'd into the correct directory at least 10 times and manually loaded the correct gemset, this is not the issue.
Can't figure out why it works fine in development, but not in production. I know there used to be a scripts directory a while back (maybe rails 2?)- Is there still a directory that contains the script commands for rails that may have been corrupted?
Has anyone ever experienced this before or have any suggestions?
I feel like I am missing something.
Ok, found the issue... #stoodfarback was pretty close, but I thought the cause of the issue needed to be mentioned for others who might encounter the same thing.
Basically I am using a newer version of Capistrano (3.3.5) than I have used in the past and it (by default) adds 'bin' to the list of shared directories that it symlinks on each deploy.
set :linked_dirs, fetch(:linked_dirs, []).push('bin', 'log', 'tmp', 'public/system', "public/downloads", "public/assets")
So the deploy script created a new directory in shared called bin (which was empty) and the files used to launch rails server and console were missing. They were obviously still there in development, so it only affected production.
Removed 'bin' from the linked_dirs list and everything now works as expected.
now looks like:
set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp', 'public/system', "public/downloads","publ ic/assets")
I have noticed on the last few versions of Capistrano that I have used, the format and defaults for linked_dirs keeps changing quite a bit, but I had never seen bin in that list. Not really sure why bin would need to be symlinked... it only has the default rails files and I can't think of why they would need to be removed from source control, but maybe the Capistrano team has a reason.
Hope this helps someone.
Check if you have any of these files and try deleting them:
script/rails
bin/rails
I am on Rails 4.0.0
So, I have created a new app in a new directory: rails new lpd.
I have cd' into the new lpd directory.
bundle install gives me Bundler::GemFileNotFound.
rails s does not start the server.
I cd in to another project that has a Gemfile installed, do a bundle install, that works fine and the rails server starts fine.
I cd back into my new project directory lpd and hit rails s again, no luck.
still GemFileNotFound.
There is no Gemfile in the project directory.
You can:
A. Create one yourself using a Rails 4.0 Gemfile as a template.
B. Copy one over from another Rails 4.0 project.
C. Run rails new again to recreate the project files (be careful to backup any changes you have already made such as configuration changes).
Good afternoon,
I just upgraded my Rails app from 3.1.3 to 3.2.1. Everything is working on my local development machine (in development or production modes). There is no trace left of my vendor/plugins directory (or even the vendor directory at all).
However, after committing to git and pushing to Heroku, I'm getting warnings about deprecation of my rails 2.3 style vendor/plugins. Crazy seeing as I have no vendor directory at all!
Do I need to totally wipe my Heroku files? (If so, how would I do this?) Any other suggestions appreciated.
I've seen this and it looks like warnings about some of the stuff that Heroku injects into your code for things such as asset serving etc.
I'm assuming that as more and more start to use Rails 3.2 that Heroku will fix this. I wouldn't worry about it - the deprecation won't kick in until Rails 4.0 and that's some way off.
I've inherited a rails site that I need to deploy (quickly!) to our webhost, which is a standard *nix shared server that uses FastCGI for rails apps. I've worked with rails sites on multiple occasions in the past but wouldn't consider myself an expert by any stretch.
This particular app was developed using capistrano, with which I've got no experience, and everything I've read leads me to believe that to deploy the app "properly" would require my setting up an external svn account, among other things, which aren't feasible given our time frame and hosting situation.
My question is: what is the best way to quickly get this application up and running without using capistrano? I received, along with the site files, a .sql dump that I've already imported, and I've configured config/database.yml to reflect the correct production db settings. Right now, running ruby script/console production yields the following error message:
/home/user1/ruby/gems/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:443:in `load_missing_constant':NameError: uninitialized constant ApplicationController
Thanks for your consideration!
As the others already stated, you are probably using the incorrect version.
Rails switched from app_controller to application_controller (or something like that) in version 2.1 or 2.2.
There is a rake task that you should be able to run in that case:
rake rails:update:application_controller
It might help you.
As for the capistrano. In your deploy.rb you can add the parameter :deploy_via :
set :deploy_via, :copy
set :scm, :none
And it should use the copy you are having in your working directory to deploy with (no need for subversion or any other version control)
Copy usually fetches the code from a repository locally and then uploads it to the server, but also setting the :scm to none it should ignore that and just (hopefully) use your working copy instead.
All capistrano requires is a deploy.rb and a Capfile, this is not what is causing your error. From the looks of it it seems that the problem is that you're using a gem rails version which is incompatible with your app, do you know which version it was developed with? If so you should try vendoring your rails directory to the right version.
For deployment, if you're using FastCGI you can just upload the files to the host and set the appropriate permissions and you should be good to go. Going forward you might want to look at upgrading to a newer version of rails, using capistrano and changing your environment to use apache passenger.
I hope this helps.
The problem you're running into appears to be a mismatch of your installed version and the version that the app is expecting. Look in config/environment.rb, Toward the top you'll see something that looks like:
RAILS_GEM_VERSION = '2.3.4'
You need to make sure that the version of rails installed on your machine matches whatever version is declared in that file. You can do that by running:
sudo gem install -v=X.X.X rails
where X.X.X matches what was in your environment.rb.
Jonnii is suggesting you "freeze" your rails by including all the rails code into your project directly, (which can be done by running rake rails:freeze:gems AFTER you have followed the above steps and gotten the correct gems installed in the first place.) Once you've frozen rails, then you no longer need to have the rails gems installed on your webserver machine.
Good luck!