-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't run migrate
when deploying non-Rails apps
#49
Comments
migrate
wen deploying non-Rails appsmigrate
when deploying non-Rails apps
Makes sense to me. We also have |
I was against adding I'm thinking about 1) checking to see if |
When using Parity with a Python project, the `deploy` subcommand was causing harmless but annoying error messages when the deploy step for running migrations was attempted. This change checks that the `rake` command is available to the application and that the application has a `db:migrate` task defined (using Rake's `-n` switch for a "dry run"). Fix #49.
When using Parity with a Python project, the `deploy` subcommand was causing harmless but annoying error messages when the deploy step for running migrations was attempted. This change checks that the `rake` command is available to the application and that the application has a `db:migrate` task defined (using Rake's `-n` switch for a "dry run"). Other changes: * Stub out `Kernel.system` in environment specs to always return true unless explicitly told otherwise. Many of our specs stubbed out `.system` just to keep execution moving forward. Stubbing out across all the specs also prevents accidental execution of commands in a spec where stubbing was not set up. Fix #49.
When using Parity with a Python project, the `deploy` subcommand was causing harmless but annoying error messages when the deploy step for running migrations was attempted. This change checks that the `rake` command is available to the application and that the application has a `db:migrate` task defined (using Rake's `-n` switch for a "dry run"). Other changes: * Stub out `Kernel.system` in environment specs to always return true unless explicitly told otherwise. Many of our specs stubbed out `.system` just to keep execution moving forward. Stubbing out across all the specs also prevents accidental execution of commands in a spec where stubbing was not set up. Fix #49.
When using Parity with a Python project, the `deploy` subcommand was causing harmless but annoying error messages when the deploy step for running migrations was attempted. This change checks that the `rake` command is available to the application and that the application has a `db:migrate` task defined (using Rake's `-n` switch for a "dry run"). Other changes: * Stub out `Kernel.system` in environment specs to always return true unless explicitly told otherwise. Many of our specs stubbed out `.system` just to keep execution moving forward. Stubbing out across all the specs also prevents accidental execution of commands in a spec where stubbing was not set up. Fix #49.
Experimenting with a Python app we're using at @cortexintel and the Homebrew version of Parity has been useful. The
deploy
command runs fine, but gives us some errors about migrations.Wondering if we should detect if it's a Rails app before we decide to run
migrate
.The text was updated successfully, but these errors were encountered: