Skip to content
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

Closed
geoffharcourt opened this issue Sep 8, 2015 · 2 comments
Closed

Don't run migrate when deploying non-Rails apps #49

geoffharcourt opened this issue Sep 8, 2015 · 2 comments

Comments

@geoffharcourt
Copy link
Collaborator

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.

@geoffharcourt geoffharcourt changed the title Don't run migrate wen deploying non-Rails apps Don't run migrate when deploying non-Rails apps Sep 28, 2015
@croaky
Copy link
Contributor

croaky commented Nov 6, 2015

Makes sense to me. We also have bin/deploy scripts in most of our apps. Thoughts on removing the deploy command in Parity?

@geoffharcourt
Copy link
Collaborator Author

I was against adding deploy when it was first suggested, but it's become pretty essential as I've started working on a wider number of apps at a time. On our latest project, we're actually using parity in our bin/deploy script.

I'm thinking about 1) checking to see if rake is a valid command and 2) checking if migrate is a valid task. Would looking for the existence of db/migrate be a better strategy?

geoffharcourt added a commit that referenced this issue Nov 6, 2015
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.
geoffharcourt added a commit that referenced this issue Nov 6, 2015
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.
geoffharcourt added a commit that referenced this issue Nov 6, 2015
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.
geoffharcourt added a commit that referenced this issue Nov 6, 2015
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants