Closed senid231 closed 5 years ago
Oh neat, I've always loved this technique. Wanna covert it to a non-draft PR and let the tests run?
@metaskills I've been thinking about adding tests for case when we have namespaced active_record tasks
@metaskills looks like tests wasn't started automatically
Interesting, I wonder if Draft PRs never trigger the tests? I'd say if this change just passes existing test, we are good.
@metaskills draft PRs actually trigger tests in same way as normal PR does. Today I've added similar draft PR to parallel_tests
and tests was started simultaneously.
Agreed, but I think something might be odd in our /customink
org. I heard from GitHub Enterprise support the other day about issues getting the Draft feature working correctly for us in both public and private repos. So assuming this is why I do not see a build triggered in TravisCI here https://travis-ci.org/customink/secondbase/pull_requests
Maybe create a new PR to test? No pun :)
@metaskills looks like tests started when I add ordinary PR #63
@metaskills but when I delete new PR ci jobs started to fail interesting behavior) I'll close this PR and move description to new one
When you are developing rails engine which has connects with two databases you don't have ordinary rails tasks like
db:migrate
db:structure:load
etc. They are moved intoapp
namespace.so instead of
rake db:migrate
you need to rightrake app:db:migrate
.when you use gem with
railtie
that has rake tasks in rails engine those task namespaced intoapp
too. Problem appears when you want to run another rake task inside of yours. For example when we insideapp
namespace we need to runapp:db:migrate
instead of `db:migrate.in this PR I've solved this problem in a same way as
active_record
does - just call tasks using name related to currentdb
namespace