I generated a skeleton application using Rails Composer and included Figaro. It runs successfully locally. Before I modify it, I am pushing it down to Heroku. However, the heroku run rake db:seed failed. I've come to find out that the app/config/application.yml is .gitignored. So, I need to use rake figaro:heroku to set the environment variables before I run heroku run rake db:seed. But, the rake Figaro:heroku is failing as follows:
D:\BitNami\rubystack-2.0.0-11\projects\myapp>rake figaro:heroku
! Usage: heroku config:set KEY1=VALUE1 [KEY2=VALUE2 ...]
! Must specify KEY and VALUE to set.
This looks like it is just ignoring my app/config/application.yml and asking for line directed input to me, but I don't know. Again, the application runs successfully locally, so that application.yml should be correct. Here it is:
MANDRILL_USERNAME: valid.address#gmail.com
MANDRILL_APIKEY: a.valid.apikey
ADMIN_NAME: Admin Name
ADMIN_EMAIL: valid.address#gmail.com
ADMIN_PASSWORD: validpassword
ROLES: [admin, user, VIP]
The failure occurs in seeds when I issue heroku run rake db:seed. The file is:
puts 'ROLES'
YAML.load(ENV['ROLES']).each do |role|
Role.find_or_create_by_name(role)
puts 'role: ' << role
end
puts 'DEFAULT USERS'
user = User.find_or_create_by_email :name => ENV['ADMIN_NAME'].dup, :email => ENV['ADMIN_EMAIL'].dup, :password => ENV['ADMIN_PASSWORD'].dup, :password_confirmation => ENV['ADMIN_PASSWORD'].dup
puts 'user: ' << user.name
user.confirm!
user.add_role :admin
It fails on the first access to variable role because ENV['ROLES'] is uninitialized. It would be initialized by application.yml, and is locally, but it is .gitignored. Thus, the need for rake Figaro:heroku to succeed.
This seems so simple, especially since it runs smoothly locally. OBTW, I have tried application.yml as shown and with the strings double-quoted but it doesn't seem to make a difference in any case so...
Ideas? Thanks...
I understand from the path you're mentioning that this is a Windows question. Problem is that the arrays are not correctly dealt with on Windows. Workaround I once made is to override the "vars" method of Heroku in a rake file in lib/tasks, like
module Figaro
module Tasks
class Heroku # < Struct.new(:app)
def vars
Figaro.env(environment).map { |key, value|
if value.start_with? "["
value = "'#{value.gsub('"', '')}'"
elsif value.include? " "
value = "'#{value}'"
end
"#{key}=#{value}"
}.sort.join(" ")
end
end
end
end
I'd surmise the problem will likely be with Figaro's processing of your different variable types:
MANDRILL_USERNAME: "valid.address#gmail.com"
MANDRILL_APIKEY: "a.valid.apikey"
ADMIN_NAME: "Admin Name"
ADMIN_EMAIL: "valid.address#gmail.com"
ADMIN_PASSWORD: "validpassword"
ROLES: ["admin", "user", "VIP"]
Try removing any spaces & ensuring you only send KEY: "VALUE" to Figaro. Your spaces are basically going to cause the system to misinterpret it
Related
Is there any conventions of rails or a right way to create/manipulate a table that will contain just one row?
If not, what is the best way to do that?
I need a way to store configurations of the system.
Thanks.
Edited:
The rake db:seed command, basically execute whatever code you write in db/seeds.rb file of your application. Though can write any code in this file, by convention you should write code which populate your database with the basic data,
for example: when ever your deploy your application somewhere, and create a new database for it, you want that user with admin credential must be present there. So you will write the code which create that user in this file. Below is the sample code which will create a user and assign admin role to him.
puts "********Seeding Data Start************"
admin = User.create(:first_name => 'System', :last_name => 'Admin',
:email => 'systemadmin#sunpower.com', :password => 'sunpoweradmin',
:password_confirmation => 'sunpoweradmin', :source_system_id => 'systemadmin',
:source_system => 'LP',:entity_type => "Customer", :target_system => "OPENAM")
if admin.errors.blank?
puts "***User #{admin.first_name} #{admin.last_name} created ***"
admin.add_role :admin # add_role is method defined by rolify gem
puts "***admin role assigned to #{admin.first_name} #{admin.last_name}***"
else
puts "admin user failed to create due to below reasons:"
admin.errors.each do |x, y|
puts"#{x} #{y}" # x will be the field name and y will be the error on it
end
end
puts "********Seeding Data End************"
Now whenever you recreate your database, you just need to run below command to populate the database, with the basic data
$ rake db:seed RAILS_ENV=production
The correct order to setup database in production, with all the rake task available within db namespace is as below
$rake db:create RAILS_ENV=production
$rake db:migrate RAILS_ENV=production
$ rake db:seed RAILS_ENV=production
NOTE: You can replace the first two commands with $rake db:setup RAILS_ENV=production , it will run both create and migrate internally
OR
You could use the rails-settings-cached gem which is a fork of the rails-settings gem
Once setup, you'll be able to do things such as:
Setting.foo = 123
Setting.foo # returns 123
Hope this may help you or what you are looking for..
I've got the following configuration line in my production.rb environment file, as instructed in this article:
config.cache_store = :mem_cache_store, ENV["MEMCACHEDCLOUD_SERVERS"].split(','), { :username => ENV["MEMCACHEDCLOUD_USERNAME"], :password => ENV["MEMCACHEDCLOUD_PASSWORD"] }
But when I try to deploy, I'll get an error:
Running: rake assets:precompile rake aborted!
undefined method split' for nil:NilClass
/tmp/build_abdc.../config/environments/production.rb:107:inblock in '
This is because config vars are not available during compilation. There's a Heroku labs add-on that you can supposedly use to remedy this, but it comes with a warning from Heroku that "Using this labs feature is considered counter to Heroku best practices."
So then what is the best practice when it comes to using ENV vars in production config? Should they just all be wrapped in rescue handlers so that Heroku ignores them during compilation?
We ended up just checking for the ENV var before assigment. It looks like that's the pattern you need whenever you use ENV vars in config/initializers on Heroku:
# NOTE: ENV vars aren't available during slug compilation, so we must check if they exist:
if ENV["MEMCACHEDCLOUD_SERVERS"]
config.cache_store = :mem_cache_store, ENV["MEMCACHEDCLOUD_SERVERS"].split(','), { :username => ENV["MEMCACHEDCLOUD_USERNAME"], :password => ENV["MEMCACHEDCLOUD_PASSWORD"] }
end
See also:
https://devcenter.heroku.com/articles/rails-asset-pipeline#failures-in-the-assets-precompile-task
I have recently deployed my Ruby on Rails app from running it locally on my machine to a VPS server. The Administration section isn't working, with username and password. It works locally, but online, I can't get in to administer my user details. The rest of the app seems to be working ok, just not the Admin.
In my db/seeds.rb I have:
Admin.create(:email => "admin#admin.com", :password => "admin_password")
#unless Rails.env.production?
# 1000.times do
# Factory.create(:user)
# end
#end
categories_file = File.join(Rails.root, 'config', 'categories.txt')
if File.exists?(categories_file)
File.open(categories_file, 'r') do |f|
while category = f.gets
Category.create(:name => category)
end
end
end
Is there something I need to do to get it working correctly? Thanks.
Someone ran:
RAILS_ENV=production bundle exec rake db:seed
from the production instance (whatever that is) on the server, and now it's working.
We're doing an upgrade to Ruby on Rails 3 (like half the world right now), and I've been diligently replacing usages of RAILS_ENV, for example
RAILS_ENV == 'wibble'
# becomes
Rails.env.wibble?
But I'm not as certain of what to do with:
ENV["RAILS_ENV"] ||= 'production'
We've got it at the top of a whole bunch of Rake tasks and daemons, and the idea is that you can pass RAILS_ENV on the command-line, but it defaults to 'production' if it's not passed.
I'm not sure of the new Rails3-appropriate way of doing this. So for now my rails:upgrade:check is complaining mightily of this intrusion of Rails2-ishness...
I don't know if:
::Rails.env ||= 'production'
will work.
Does Rails.env exist in a daemon?
Does it automagickally get pre-populated with the value of RAILS_ENV passed on the command-line or do we need a new way of invoking the daemons?
What is the correct mantra for this?
Update:
Looking into the source-code for Rails.env,
def env
#_env ||= ActiveSupport::StringInquirer.new(RAILS_ENV)
end
we can deduce a number of things.
Firstly, it looks like RAILS_ENV does actually still exist - which means it can be set and Rails.env will find it...
If Rails is valid in the context of a daemon, then nothing more needs to be done. If not - then I could just not care much and use the old RAILS_ENV as before.
Rails.env is actually of type ActiveSupport::StringInquirer, which overrides method_missing in order to provide that nice equality syntax. Check: http://api.rubyonrails.org/classes/ActiveSupport/StringInquirer.html
So, if you want to override it to be "production" by defaut, you should write:
Rails.env ||= ActiveSupport::StringInquirer.new('production')
However, you'll have to check which is the uninitialized value of Rails.env, I'm not sure it's really nil.
The best course of action, IMO, is to just prepend env RAILS_ENV=production to all your scripts.
Edit lib/tasks/environments.rake
# Sets environments as needed for rake tasks
%w[development production staging].each do |env|
desc "Runs the following task in the #{env} environment"
task env do
Rails.env = env
end
end
task :testing do
Rake::Task["test"].invoke
end
task :dev do
Rake::Task["development"].invoke
end
task :prod do
Rake::Task["production"].invoke
end
Source
UPDATE
pass RAILS_ENV=production via command line, something like this:
RAILS_ENV=production rake db:setup
Does this help:
# before
if RAILS_ENV == 'production'
...
# Rails 3
if Rails.env.production?
if Rails.env.production?
puts '...'
I've been using the Authlogic rails plugin. Really all I am using it for is to have one admin user who can edit the site. It's not a site where people sign up accounts. I'm going to end up making the create user method restricted by an already logged in user, but of course, when I clear the DB I can't create a user, so I have to prepopulate it somehow. I tried just making a migration to put a dump of a user I created but that doesn't work and seems pretty hacky. What's the best way to handle this? It's tricky since the passwords get hashed, so I feel like I have to create one and then pull out the hashed entries...
Rails 2.3.4 adds a new feature to seed databases.
You can add in your seed in db/seed.rb file:
User.create(:username => "admin", :password => "notthis", :password_confirmation => "notthis", :email => "admin#example.com")
Then insert it with:
rake db:seed
for production or test
RAILS_ENV="production" rake db:seed
RAILS_ENV="test" rake db:seed
My favorite feature in 2.3.4 so far
If you are using >= Rails 2.3.4 the new features include a db/seeds.rb file. This is now the default file for seeding data.
In there you can simple use your models like User.create(:login=>"admin", :etc => :etc) to create your data.
With this approach rake db:setup will also seed the data as will rake db:seed if you already have the DB.
In older projects I've sometimes used a fixture (remeber to change the password straight away) with something like users.yml:
admin:
id: 1
email: admin#domain.com
login: admin
crypted_password: a4a4e4809f0a285e76bb6b35f97c9323e912adca
salt: 7e8455432de1ab5f3fE0e724b1e71500a29ab5ca
created_at: <%= Time.now.to_s :db %>
updated_at: <%= Time.now.to_s :db %>
rake db:fixtures:load FIXTURES=users
Or finally as the other guys have said you have the rake task option, hope that helps.
Most used approach is to have a rake task that is run after deployment to host with empty database.
Add a rake task:
# Add whatever fields you validate in user model
# for me only username and password
desc 'Add Admin: rake add_admin username=some_admin password=some_pass'
task :add_admin => :environment do
User.create!(:username=> ENV["username"], :password=> ENV["password"],:password_confirmation => ENV["password"])
end