aboutsummaryrefslogtreecommitdiffstats
path: root/railties/test/commands
Commit message (Collapse)AuthorAgeFilesLines
* Remove mocha usageRafael Mendonça França2014-07-231-2/+5
|
* Stop using mocha on dbconsole_testRafael Mendonça França2014-07-151-44/+68
|
* Stop using mocha on console_testRafael Mendonça França2014-07-071-15/+40
|
* Isolate debugger related codeDavid Rodríguez de Dios2014-04-101-13/+19
|
* Keep debugger support only for rubies < 2.0.0David Rodríguez de Dios2014-04-081-3/+3
|
* Ensure Active Record connection consistencyschneems2014-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently Active Record can be configured via the environment variable `DATABASE_URL` or by manually injecting a hash of values which is what Rails does, reading in `database.yml` and setting Active Record appropriately. Active Record expects to be able to use `DATABASE_URL` without the use of Rails, and we cannot rip out this functionality without deprecating. This presents a problem though when both config is set, and a `DATABASE_URL` is present. Currently the `DATABASE_URL` should "win" and none of the values in `database.yml` are used. This is somewhat unexpected to me if I were to set values such as `pool` in the `production:` group of `database.yml` they are ignored. There are many ways that active record initiates a connection today: - Stand Alone (without rails) - `rake db:<tasks>` - ActiveRecord.establish_connection - With Rails - `rake db:<tasks>` - `rails <server> | <console>` - `rails dbconsole` We should make all of these behave exactly the same way. The best way to do this is to put all of this logic in one place so it is guaranteed to be used. Here is my prosed matrix of how this behavior should work: ``` No database.yml No DATABASE_URL => Error ``` ``` database.yml present No DATABASE_URL => Use database.yml configuration ``` ``` No database.yml DATABASE_URL present => use DATABASE_URL configuration ``` ``` database.yml present DATABASE_URL present => Merged into `url` sub key. If both specify `url` sub key, the `database.yml` `url` sub key "wins". If other paramaters `adapter` or `database` are specified in YAML, they are discarded as the `url` sub key "wins". ``` ### Implementation Current implementation uses `ActiveRecord::Base.configurations` to resolve and merge all connection information before returning. This is achieved through a utility class: `ActiveRecord::ConnectionHandling::MergeAndResolveDefaultUrlConfig`. To understand the exact behavior of this class, it is best to review the behavior in activerecord/test/cases/connection_adapters/connection_handler_test.rb though it should match the above proposal.
* Fix DB Console tests schneems2013-12-211-20/+22
| | | | | | | | | | | The build is broken: https://travis-ci.org/rails/rails/builds/15824530 This commit fixes it. The problem: Sqlite expects the `database` part to be an absolute path. That prompted this change to be committed to master: https://github.com/rails/rails/commit/fbb79b517f3127ba620fedd01849f9628b78d6ce This change provides correct behavior. Unfortunately tests were introduced in https://github.com/rails/rails/commit/971d5107cd4cd08c22a85d34546f4ba03ed5c925 that were relying on the incorrect behavior. We can avoid the fix by changing to another database url such as `mysql` or `postgresql` In addition to fixing the failure, the assertions are changed so that the "expected" value comes before "actual" value.
* fixed rails dbconsole to support ENV['DATABASE_URL'].Huiming Teo2013-12-161-27/+67
|
* Make logging to stdout work again with implicit `development` envMarc Schütz2013-10-131-12/+48
|
* Only output Server logs in Developmentschneems2013-09-221-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now when you start a server via `rails s`, the logger gets extended so that it logs to the file system and also to stdout. This extension behavior is not "intelligent" and if the default logger is already set to output to stdout, then the contents will be received twice. To capture logs in accordance with http://www.12factor.net/logs some platforms require the logs to be sent to standard out. If a logger is set to stdout, and the server is started using `rails server` instead of another method (i.e. `thin start` etc.) then the app will produce double logs. This PR fixes the issue by only extending the logger to standard out in the development environment. So that in production you don't get double logs like this: ``` ActionView::Template::Error (wrong number of arguments (5 for 4)): 1: <% lang_index = 0 %> 2: <div class="row"> 3: <ul class="nav nav-tabs nav-stacked span2" data-tabs="tabs" id="repo-tabs"> 4: <% repos.group_by(&:language).each do |lang, repos| %> 5: <% unless lang == nil %> 6: <li><a href="#<%= "#{lang.parameterize}#{lang.hash}" %>" data-toggle="tab"><%= lang %></a></li> 7: <% end -%> app/views/shared/_repos.html.erb:4:in `_app_views_shared__repos_html_erb___1685450633638247395_70300668607000' app/views/pages/index.html.erb:13:in `_app_views_pages_index_html_erb__2084723628308867770_70300687584880' ActionView::Template::Error (wrong number of arguments (5 for 4)): 1: <% lang_index = 0 %> 2: <div class="row"> 3: <ul class="nav nav-tabs nav-stacked span2" data-tabs="tabs" id="repo-tabs"> 4: <% repos.group_by(&:language).each do |lang, repos| %> 5: <% unless lang == nil %> 6: <li><a href="#<%= "#{lang.parameterize}#{lang.hash}" %>" data-toggle="tab"><%= lang %></a></li> 7: <% end -%> app/views/shared/_repos.html.erb:4:in `_app_views_shared__repos_html_erb___1685450633638247395_70300668607000' app/views/pages/index.html.erb:13:in `_app_views_pages_index_html_erb__2084723628308867770_70300687584880' ``` ATP Railties. Opened against master in favor of #10999
* fix private attribute warningVipul A M2013-04-042-3/+6
|
* Fix failing test regarding console change to fix sandboxingCarlos Antonio da Silva2013-03-081-11/+10
| | | | Introduced in be3e10cd26bc8ec29c6474d03a08a8e733108e7d.
* This commit fixes issue #8628Mykola Kyryk2013-01-042-0/+18
| | | | | | | | | | | | Allow environment name to start with a substring of the default environment names. For example: tes, pro, prod, dev, devel, etc. Fixing identation. Adding test for Rails::Console.parse_arguments method. Fix issue 8628 for Rails::DBConsole.
* Refactor tests that switch RAILS_ENV and RACK_ENVCarlos Antonio da Silva2012-12-062-34/+14
| | | | | | | | | | | | This cleanup aims to fix a build failure: https://travis-ci.org/rails/rails/jobs/3515951/#L482 Since travis always have both ENV vars set to "test", a test is failing where it's expected to output the default env "development", but "test" is the result due to RACK_ENV being set when we expect it to not be. By cleaning this duplication we ensure that changing any of these env variables will pick the right expected value.
* Add ENV['RACK_ENV'] support to rake runner/console/server.kennyj2012-12-062-2/+37
|
* Fix rails db command with sqlite3 databaseCarlos Antonio da Silva2012-11-181-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | When using sqlite3 it was attempting to find the database file based on Rails.root, the problem is that Rails.root is not always present because we try to first manually load "config/database.yml" instead of loading the entire app, to make "rails db" faster. This means that when we're in the root path of the app, calling "rails db" won't allow us to use Rails.root, making the command fail for sqlite3 with the error: ./rails/commands/dbconsole.rb:62:in `start': undefined method `root' for Rails:Module (NoMethodError) The fix is to simply not pass any dir string to File.expand_path, which will make it use the current directory of the process as base, or the root path of the app, which is what we want. When we are in any other subdirectory, calling "rails db" should work just fine, because "config/database.yml" won't be found, thus "rails db" will fallback to loading the app, making Rails.root available. Closes #8257.
* Removing warning : assigned but unused variableArun Agrawal2012-11-101-1/+1
|
* Use Ruby 1.9 Hash syntax in railtiesRobin Dupret2012-10-141-4/+4
|
* warning fixed: ambiguous first argument; put parentheses or even spacesArun Agrawal2012-10-101-7/+7
|
* Set RACK_ENV to nil in the dbconsole testRafael Mendonça França2012-05-301-0/+1
| | | | This will fix the travis-ci build
* Remove support for rails server RAILS_ENV=env-nameSam Oliver2012-05-301-2/+2
|
* Fix various bugs with console arguments.Sam Oliver2012-05-302-39/+71
| | | | Allow hyphens in environment names again.
* More assert_match warnings fixed.Arun Agrawal2012-05-302-8/+8
|
* Fix `rails db -h` and cosmetic fixes in usage bannersAlexey Vakhov2012-05-221-0/+18
| | | | | | | Ruby tries to use '-h' as short version of '--header' by default https://github.com/ruby/ruby/blob/trunk/lib/optparse.rb#L1372-1381. To force `rails db -h` prints an usage message we should add the `-h` options explicitly.
* Use relative path to sqlite3 db in `rails db` commandAlexey Vakhov2012-05-221-6/+11
| | | | | | | | | | Rails uses sqlit3 db file with a path relative to the rails root. It allows to execute server not from rails root only. For example you can fire `./spec/dummy/script/rails s` to start dummy application server if you develop some engine gem. Now the `rails db` command uses relative paths also and you can explore your dummy db via `./spec/dummy/script/rails db` command.
* Fix buildPiotr Sarnacki2012-05-061-7/+10
|
* More faster rails dbconsoleDmitry Vorotilin2012-05-061-28/+57
|
* Add Rails::DBConsole testsAlexey Vakhov2012-05-021-0/+128
|
* match rails console environment support, to serverschneems2012-03-221-0/+19
| | | | rails server takes `-e` as an argument to specify RAILS_ENV, rails console currently does not have the same interface. This commit fixes this disparity so developers can manually specify `RAILS_ENV` or can pass in an environment with a `-e`.
* fix rails server support of RAILS_ENV variableschneems2012-03-201-0/+26
| | | | | | | When launching rails server from the command line with a rails environment specified such as `rails server RAILS_ENV=production` an error would occur since rails will try to use `RAILS_ENV=production` as it's server. When launching rails with a specified server such as thin `rails server thin RAILS_ENV=production` no error will be thrown, but rails will not start up in the specified environment. This fixes both of those cases
* Fix tests, Rails.env may be different on CIPiotr Sarnacki2012-02-161-2/+5
|
* Refactor Rails::Console to make it easier to test and add tests for itPiotr Sarnacki2012-02-161-0/+84