I get this error when trying to deploy with capistrano 3.
cap production deploy:setup
cap aborted!
cannot load such file -- capistrano/mercurial.rb
my deploy:
...
set :branch, "default"
set :deploy_to, "/var/rails"
set :deploy_via, :remote_cache
set :scm, 'mercurial'
...
Do I need some kind of extension? The only I've found so far is Capistrano-Mercurial-Ext but it didn't help.
Looking at the Capistrano 3 sourcecode in GitHub the Mercurial SCM task is called 'hg':
https://github.com/capistrano/capistrano/blob/master/lib/capistrano/tasks/hg.rake
So try changing the line:
set :scm, 'mercurial'
To be:
set :scm, :hg
Related
I've been struggling to run bundle exec rake ts:index in my sharetribe project. It's returning an error:
rony#ronyMacMini sharetribe % bundle exec rake ts:index
Generating configuration to /Users/rony/Documents/freelensia Ofc/sharetribe/config/development.sphinx.conf
DEBUG (1.0ms) SET NAMES utf8, ##SESSION.sql_mode = CONCAT(CONCAT(##sql_mode, ',STRICT_ALL_TABLES'), ',NO_AUTO_VALUE_ON_ZERO'), ##SESSION.sql_auto_is_null = 0, ##SESSION.wait_timeout = 2147483
DEBUG ↳ app/indices/custom_field_value_index.rb:8
DEBUG Delayed::Backend::ActiveRecord::Job Destroy (4.2ms) DELETE FROM `delayed_jobs` WHERE (handler LIKE ('--- !ruby/object:ThinkingSphinx::Deltas::%') AND locked_at IS NULL AND locked_by IS NULL AND failed_at IS NULL)
DEBUG ↳ /Users/rony/.rvm/gems/ruby-2.6.5/bin/rake:23
Sphinx 3.3.1 (commit b72d67bc)
Copyright (c) 2001-2020, Andrew Aksyonoff
Copyright (c) 2008-2016, Sphinx Technologies Inc (http://sphinxsearch.com)
using config file '/Users/rony/Documents/abc/sharetribe/config/development.sphinx.conf'...
ERROR: unknown key name 'docinfo' in /Users/rony/Documents/abc/sharetribe/config/development.sphinx.conf line 40 col 10.
FATAL: failed to parse config file '/Users/rony/Documents/abc/sharetribe/config/development.sphinx.conf'
The Sphinx indexing command failed:
Command: indexer --config "/Users/rony/Documents/abc/sharetribe/config/development.sphinx.conf" --all
Status: 1
Output: See above
There may be more information about the failure in /Users/rony/Documents/abc/sharetribe/log/development.searchd.log.
Note that: To install thinking-sphinx on my mac, I’ve downloaded a
pre-built set of binaries and copy-pasted content of bin inside
usr/local/bin.
Searched everywhere but couldn't found the solution. I'm sure I'm missing some stupid thing.
Please help me to fix it.
Update
Downgraded sphinx to 2.2.11. Now another issue raised:
dyld: Library not loaded: /opt/local/lib/mysql55/mysql/libmysqlclient.18.dylib
Referenced from: /usr/local/bin/indexer
Reason: image not found
zsh: abort indexer
I think /opt/local is not correct system directory format for mac. :(
This is due to recent versions of Sphinx removing the docinfo setting.
Which version of Thinking Sphinx is Sharetribe using? If it's 4.x, you can disable the docinfo settings by adding skip_docinfo: true to each appropriate environment in config/thinking_sphinx.yml. For example:
development:
skip_docinfo: true
In Thinking Sphinx v5.0, docinfo is no longer used, but upgrading requires a bit of work with adding callbacks to all indexed models.
If you're using Thinking Sphinx v3.x, then you'll need to downgrade your version of Sphinx to v2.2.11.
Had a Jekyll running fine 3 days ago. Today its failing and I suspect it due to a system update on my Windows machine. Problem is, I can't figure out how to troubleshoot this. I get the error below when attempting to run "Jekyll serve", even though I've been able to verify the location of the file..
I've tried removing and re-cloning the repository several times and in multiple root path locations. This despite the fact that this worked 3 days ago. So any pointers on where to look for the root cause would be appreciated.
E, [2015-02-22T13:01:45.263372 #8332] ERROR -- : Actor crashed!
Errno::ENOENT: No such file or directory - C:/Users/brestin.... insert long path here .../node_modules C:/Ruby193/lib/ruby/gems/1.9.1/gems/listen-2.7.11/lib/listen/record.rb:113:in open'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/listen-2.7.11/lib/listen/record.rb:113:inentries'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/listen-2.7.11/lib/listen/record.rb:113:in _fast_build'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/listen-2.7.11/lib/listen/record.rb:65:inblock in build'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/listen-2.7.11/lib/listen/record.rb:64:in each'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/listen-2.7.11/lib/listen/record.rb:64:inbuild'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/celluloid-0.16.0/lib/celluloid/calls.rb:26:in public_send'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/celluloid-0.16.0/lib/celluloid/calls.rb:26:indispatch'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/celluloid-0.16.0/lib/celluloid/calls.rb:63:in dispatch'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/celluloid-0.16.0/lib/celluloid/cell.rb:60:inblock in invoke'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/celluloid-0.16.0/lib/celluloid/cell.rb:71:in block in task'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/celluloid-0.16.0/lib/celluloid/actor.rb:357:inblock in task'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/celluloid-0.16.0/lib/celluloid/tasks.rb:57:in block in initialize'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/celluloid-0.16.0/lib/celluloid/tasks/task_fiber.rb:15:inblock in create'
jekyll 2.4.0 | Error: No such file or directory - C:/Users/brestin.... insert long path here .../node_modules
Try adding exclude: [node_modules] to your configuration file.
I use spork and guard to speed up the test suite in my Rails 3.2 application. However the tests in guard behave strange after adding a new migration: they act as they don't know about the changes in schema, even though I run rake db:migrate before. They start to behave correctly when I stop guard and run rake spec. I suppose that it behaves this way, because spork/guard doesn't update schema before tests. Is it possible to configure spork to update schema on #prefork and guard to reload spork on schema changes?
You need to run rake db:test:prepare to apply migrations for testing environment.
Theoretically the following default Spork setup code should reload schema each time a test is run. Do you have it?
ActiveRecord::Schema.verbose = false
silence_stream STDOUT do
load Rails.root.join('db', 'schema.rb') # use db agnostic schema by default
load Rails.root.join('db', 'seeds.rb')
end
I setup my rails project "tracks" using:
$ rails --database=mysql tracks # OK
$ cd tracks
$ vim config/database.yml # correct using mysql adapter, added password spec
$ rake db:create RAILS_ENV='development' # OK
$ rake db:migrate # OK
$ ruby script/generate scaffold user name:string password:string email:string url:string # OK
$ rake db:migrate # OK, creates table
$ ruby script/server # OK, starts WEBrick
I open up the thing in a web browser:
http://localhost:3000 # correctly shows the rails welcome splash
I navigate to
http://localhost:3000/users/new
and get a huge slew of errors:
ActiveRecord::StatementInvalid in UsersController#index
SQLite3::SQLException: no such table: users: SELECT * FROM "users"
RAILS_ROOT: /home/drew/tracks/trunk/tracks
Application Trace | Framework Trace | Full Trace
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:188:in `log'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:132:in `execute'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:372:in `catch_schema_changes'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:132:in `execute'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:275:in `select'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `select_all_without_query_cache'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:81:in `cache_sql'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
vendor/rails/activerecord/lib/active_record/base.rb:635:in `find_by_sql'
vendor/rails/activerecord/lib/active_record/base.rb:1490:in `find_every'
vendor/rails/activerecord/lib/active_record/base.rb:589:in `find'
app/controllers/users_controller.rb:5:in `index'
wtf? Why is ruby still trying to use SQLite? database.yml has zero mention of SQLite.
Thanks
Couldn't figure it out. I ended up reinstalling the OS on the VM and trying again and it worked.
FYI: Do not install rubygems from a package manager like apt-get. Compile it from source or it will all end in tears.
Had this problem, I found all of the files using "find . | xargs grep 'sqlite3' -sl then replaced all of the yml and rb files it found then restarted the server.
Unfortunately, I don't know which (if any, as it may have been the server restart) solved the issue, but now I'm on and up.
Hope that helps someone, however 'hacky'.
Quick Fix that i've used is...
When i start a project a specify the -d for database
rails -d mysql ProjectName
Which builds the database.yml file for mysql
hope this helps.
As odd as it might sound, try clearing your browser's cookies. I had a similar problem moving from sqlite to postgresql and vice versa. It turns out the stored cookie or session was somehow making the server get stuck in using the old database. If this works then you'll want to take steps on your server to invalidate any existing cookies in your users' browsers.
Don't mean to necro, but if someone runs onto this problem, edit your config/database.yml file, and remove the line that says << default from the production section. What this is doing is loading the default environment first, so Passenger loads it instead of whatever else you've configured.
I have a rails app that I'm moving to another server and I figure I should use db:schema:load to create the mysql database because it's recommended. My problem is that I'm using capistrano to deploy and it seems to be defaulting to rake db:migrate instead. Is there a way to change this or is capistrano using db:migrate for a good reason?
Why to use db:schema:load
I find that my own migrations eventually do some shuffling of data (suppose I combine first_name and last_name columns into a full_name column, for instance). As soon as I do any of this, I start using ActiveRecord to sift through database records, and your models eventually make assumptions about certain columns. My "Person" table, for instance, was later given a "position" column by which people are sorted. Earlier migrations now fail to select data, because the "position" column doesn't exist yet.
How to change the default behavior in Capistrano
In conclusion, I believe deploy:cold should use db:schema:load instead of db:migrate. I solved this problem by changing the middle step which Capistrano performs on a cold deploy. For Capistrano v2.5.9, the default task in the library code looks like this.
namespace :deploy do
...
task :cold do
update
migrate # This step performs `rake db:migrate`.
start
end
...
end
I overrode the task in my deploy.rb as follows.
namespace :deploy do
task :cold do # Overriding the default deploy:cold
update
load_schema # My own step, replacing migrations.
start
end
task :load_schema, :roles => :app do
run "cd #{current_path}; rake db:schema:load"
end
end
Climbing up on the shoulders of Andres Jaan Tack, Adam Spiers, and Kamiel Wanrooij, I've built the following task to overwrite deploy:cold.
task :cold do
transaction do
update
setup_db #replacing migrate in original
start
end
end
task :setup_db, :roles => :app do
raise RuntimeError.new('db:setup aborted!') unless Capistrano::CLI.ui.ask("About to `rake db:setup`. Are you sure to wipe the entire database (anything other than 'yes' aborts):") == 'yes'
run "cd #{current_path}; bundle exec rake db:setup RAILS_ENV=#{rails_env}"
end
My enhancements here are...
wrap it in transaction do, so that Capistrano will do a proper rollback after aborting.
doing db:setup instead of db:schema:load, so that if the database doesn't already exist, it will be created before loading the schema.
That's a great answer from Andres Jaan Tack. I just wanted to add a few comments.
Firstly, here's an improved version of Andres' deploy:load_schema task which includes a warning, and more importantly uses bundle exec and RAILS_ENV to ensure that the environment is set up correctly:
namespace :deploy do
desc 'Load DB schema - CAUTION: rewrites database!'
task :load_schema, :roles => :app do
run "cd #{current_path}; bundle exec rake db:schema:load RAILS_ENV=#{rails_env}"
end
end
I have submitted a feature request to have deploy:load_schema implemented in Capistrano. In that request, I noted that the 'db:schema:load vs. db:migrate' debate has already been covered in the Capistrano discussion group, and there was some reluctance to switch the deploy:cold task to using db:schema:load over db:migrate, since if run unintentionally, the former nukes the entire database whereas the latter would probably complain and bail harmlessly. Nevertheless db:schema:load is technically the better approach, so if the risk of accidental data loss could be mitigated, it would be worth switching.
In Capistrano 3 / Rails 4, the default deploy syntax has changed. You can do this instead:
desc 'Deploy app for first time'
task :cold do
invoke 'deploy:starting'
invoke 'deploy:started'
invoke 'deploy:updating'
invoke 'bundler:install'
invoke 'deploy:db_setup' # This replaces deploy:migrations
invoke 'deploy:compile_assets'
invoke 'deploy:normalize_assets'
invoke 'deploy:publishing'
invoke 'deploy:published'
invoke 'deploy:finishing'
invoke 'deploy:finished'
end
desc 'Setup database'
task :db_setup do
on roles(:db) do
within release_path do
with rails_env: (fetch(:rails_env) || fetch(:stage)) do
execute :rake, 'db:setup' # This creates the database tables AND seeds
end
end
end
end
If you're cautious of invoking the standard deploy tasks manually in the :cold task (as they may change in upcoming version or if you have a custom deploy task), you can also simply call deploy:db_setup before running deploy.
To perform db:schema:load instead of db:setup, you can simply change the rake task, like so:
desc 'Load DB Schema'
task :db_schema_load do
...
execute :rake, 'db:schema:load'
...
end