I'm trying to build my Ruby on Rails project from github on Travis-CI, but I 'm running into a migration problem. It runs a rake task for migration, but it complains about the same migration step after that.
It follows my .travis.yml file:
language: ruby
rvm:
- 1.9.2
before_script:
- "rake db:migrate RAILS_ENV=test"
And here's the build output:
1Using worker: ruby4.worker.travis-ci.org:travis-ruby-3
2
3
4
5$ cd ~/builds
6
7
8$ git clone --depth=100 --quiet git://github.com/rafaelportela/bacilo.git rafaelportela/bacilo
9
10
11
12$ cd rafaelportela/bacilo
13
14$ git checkout -qf 7553b7351b7a642e39ea7b55204de6cd4f320c36
15
16
17$ export TRAVIS_RUBY_VERSION=1.9.2
18
19$ rvm use 1.9.2
20Using /home/vagrant/.rvm/gems/ruby-1.9.2-p290
21
22$ ruby --version
23ruby 1.9.2p290 (2011-07-09 revision 32553) [i686-linux]
24
25$ gem --version
261.8.17
27
28
29$ export BUNDLE_GEMFILE=/home/vagrant/builds/rafaelportela/bacilo/Gemfile
30
31$ bundle install
32Fetching gem metadata from https://rubygems.org/.......
33Using rake (0.9.2.2)
34Installing i18n (0.6.0)
35Installing multi_json (1.3.4)
36Installing activesupport (3.2.2)
37Installing builder (3.0.0)
38Installing activemodel (3.2.2)
39Installing erubis (2.7.0)
40Installing journey (1.0.3)
41Installing rack (1.4.1)
42Installing rack-cache (1.2)
43Installing rack-test (0.6.1)
44Installing hike (1.2.1)
45Installing tilt (1.3.3)
46Installing sprockets (2.1.3)
47Installing actionpack (3.2.2)
48Installing mime-types (1.18)
49Installing polyglot (0.3.3)
50Installing treetop (1.4.10)
51Installing mail (2.4.4)
52Installing actionmailer (3.2.2)
53Installing arel (3.0.2)
54Installing tzinfo (0.3.33)
55Installing activerecord (3.2.2)
56Installing activeresource (3.2.2)
57Installing bcrypt-ruby (3.0.1) with native extensions
58Installing coffee-script-source (1.3.1)
59Installing execjs (1.3.1)
60Installing coffee-script (2.2.0)
61Installing rack-ssl (1.3.2)
62Installing json (1.7.0) with native extensions
63Installing rdoc (3.12)
64Installing thor (0.14.6)
65Installing railties (3.2.2)
66Installing coffee-rails (3.2.2)
67Installing orm_adapter (0.0.7)
68Installing warden (1.1.1)
69Installing devise (2.0.4)
70Installing jquery-rails (2.0.2)
71Installing pg (0.13.2) with native extensions
72Using bundler (1.1.3)
73Installing rails (3.2.2)
74Installing sass (3.1.16)
75Installing sass-rails (3.2.5)
76Installing sqlite3 (1.3.6) with native extensions
77Installing uglifier (1.2.4)
78Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
79Post-install message from rdoc:
80Depending on your version of ruby, you may need to install ruby rdoc/ri data:
81
82<= 1.8.6 : unsupported
83 = 1.8.7 : gem install rdoc-data; rdoc-data --install
84 = 1.9.1 : gem install rdoc-data; rdoc-data --install
85>= 1.9.2 : nothing to do! Yay!
86
87
88$ rake db:migrate RAILS_ENV=test
89== DeviseCreateUsers: migrating ==============================================
90-- create_table(:users)
91 -> 0.0174s
92-- add_index(:users, :email, {:unique=>true})
93 -> 0.0017s
94-- add_index(:users, :reset_password_token, {:unique=>true})
95 -> 0.0010s
96== DeviseCreateUsers: migrated (0.0239s) =====================================
97
98
99$ bundle exec rake
100You have 1 pending migrations:
101 20120508052346 DeviseCreateUsers
102Run `rake db:migrate` to update your database then try again.
103
104
105Done. Build script exited with: 1
I'd appreciate any suggestion! =]
What happens internally is that when rails db:migrate command is executed, Rails checks if db:migrate is something that rails natively supports or not. In this case db:migrate is not natively supported by rails, so Rails delegates the execution to Rake via Rake Proxy.
When you run db:migrate, rails will check a special table in the database which contains the timestamp of the last migration applied to the database. It will then apply all of the migrations with timestamps after that date and update the database table with the timestamp of the last migration.
A Rails migration is a tool for changing an application's database schema. Instead of managing SQL scripts, you define database changes in a domain-specific language (DSL). The code is database-independent, so you can easily move your app to a new platform.
Rails will already run your migrations inside a transaction if your database supports it: On databases that support transactions with statements that change the schema, migrations are wrapped in a transaction.
This blog post helped me tremendously when I was trying to get my Rails 3.2 app working with Travis CI, and write a .travis.yml
file that actually worked. Here's mine for your reference, so hope it helps:
.travis.yml
language: ruby
rvm:
- 1.9.2
- 1.9.3
env:
- DB=sqlite
- DB=mysql
- DB=postgresql
script:
- RAILS_ENV=test bundle exec rake db:migrate --trace
- bundle exec rake db:test:prepare
- bundle exec rspec spec/
before_script:
- mysql -e 'create database my_app_test'
- psql -c 'create database my_app_test' -U postgres
bundler_args: --binstubs=./bundler_stubs
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With