You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My team recently came across a really nasty issue where spring kept our ActiveRecord::Base.connection_config cached. In that case, the current ENV var based safeguards failed us (luckily nobody was seriously injured).
For example,
# First, let's run a console
> DATABASE_URL=$(heroku config:get DATABASE_URL -a my-prod-app) bin/rails console
# :tada: we're running tests against the old DATABASE_URL even though it's not set
> bin/rspec
There are lots of different ways to get into this scenario (like other code loaders or multiple ORMs that use other variables). While checking for the ENV vars works for some low hanging fruit, it doesn't let ORMs (or maybe even other app/test frameworks) make more intelligent decisions.
We actually just added this to our test suite and it works great (based on the idea in #521 (comment))
# Simplified versionDatabaseCleaner::Safeguard::CHECKS << Class.newdodefrun# Prevent running tests against protected environments# - This is the same mechanism that the `rake` tasks use so you can't# run destructive operations like `db:reset` against production
::ActiveRecord::Tasks::DatabaseTasks.check_protected_environments!endend
I think it could be very useful to modularize the concept of a Safeguard so that various ORM modules could provide their own (the above case could something like DatabaseCleaner::ActiveRecord::Safeguard::ProtectedEnvironment).
I would be more than willing to work on this, but wanted to gauge interest and possibly talk about some design decisions before going ahead with it.
The text was updated successfully, but these errors were encountered:
@thefotios I really like this idea. We're on the verge of releasing v2.0.0, so let's circle back to this after the release is made and we can look at figuring out doing something with this for v2.1.
My team recently came across a really nasty issue where
spring
kept ourActiveRecord::Base.connection_config
cached. In that case, the current ENV var based safeguards failed us (luckily nobody was seriously injured).For example,
There are lots of different ways to get into this scenario (like other code loaders or multiple ORMs that use other variables). While checking for the ENV vars works for some low hanging fruit, it doesn't let ORMs (or maybe even other app/test frameworks) make more intelligent decisions.
We actually just added this to our test suite and it works great (based on the idea in #521 (comment))
I think it could be very useful to modularize the concept of a
Safeguard
so that various ORM modules could provide their own (the above case could something likeDatabaseCleaner::ActiveRecord::Safeguard::ProtectedEnvironment
).I would be more than willing to work on this, but wanted to gauge interest and possibly talk about some design decisions before going ahead with it.
The text was updated successfully, but these errors were encountered: