[shybovycha]

Implemented rake:db migrate command, as without this one, using Rails will be meaningless.

Also added check (only text check, nothing significant) on whenether ImageMagick is installed on a node. This is usefull when, for example, you are going to use something like paperclip gem.

[cfdreddbot]

Hey shybovycha!

Thanks for submitting this pull request!

All pull request authors must have a Contributor License Agreement (CLA) on-file with us. Please sign the appropriate CLA (individual or corporate).

When sending signed CLA please provide your github username in case of individual CLA or the list of github usernames that can make pull requests on behalf of your organization.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/83272134.

[jchesterpivotal]

Hi @shybovycha,

Unfortunately, we're not going to take this PR.

1. Running rake db:migrate in a staging environment can cause irreversible changes. If the migration runs, but the application can't be deployed, there is no mechanism to rollback the database to its original state. This is because Cloud Foundry treats databases as generic services -- there is no logic baked in to open/rollback transactions or snapshot databases during staging.
2. ImageMagick is present as part of the rootfs. Each build pulls the latest stable package for the base ubuntu distribution.

We note that Heroku, whose code we base ours on, don't bake in db:migrate either.

[squeedee]

Official documentation for dealing with migrations in Rails can be found here: http://docs.cloudfoundry.org/buildpacks/ruby/gsg-ror.html

[drnic]

http://docs.cloudfoundry.org/buildpacks/ruby/rake-config.html is now the page that documents an example command + rake task for running migrations on each push/restart.