aabes (notificati...@github.com) wrote: > You can merge this Pull Request by running: > > git pull https://github.com/aabes/barclamp-crowbar rake-travis > > Or you can view, comment on it, or merge it online at: > > https://github.com/crowbar/barclamp-crowbar/pull/464 > > -- Commit Summary -- > > * add a rake task to run the travis tests in one go, so we can more easily > do that locally > > -- File Changes -- > > M crowbar_framework/Rakefile (5) > > -- Patch Links -- > > https://github.com/crowbar/barclamp-crowbar/pull/464.patch > https://github.com/crowbar/barclamp-crowbar/pull/464.diff
Posthumous +1 for the great idea! However there is a caveat that `db:drop` with `RAILS_ENV=development` will drop not only `development.sqlite3` but also `test.sqlite3`. That means that running "rake travis" with the development environment (the default) will break your test environment. I very recently tweaked ./dev's reload_test_env() to cater for this but I'm not sure what the best approach here is. Having said that, the test environment is in a dedicated tree in /tmp so maybe it doesn't matter too much? Ideas: - exclude `db:drop` from this new task - override db:drop with something which only drops the current environment's db - issue some kind of warning / ask for confirmation if interactive - do nothing and try to be aware of this corner case I believe there are only 3 use cases for this task: 1) Called by Travis via .travis.yml 2) Called by dev's reload_test_env() 3) Called manually from the CLI This new task lets us eliminate small amount of duplication between .travis.yml and ./dev, which is cool. Any other use cases? FWIW 1) is always non-interactive, 2) is typically interactive but could be non-interactive, and 3) is almost always interactive. _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
