Gemspec file and Rails 5 support
Closed this issue · 14 comments
Hi Justin!
First of all, thanks for actively developing this Cypress-Rails integration. We've used Cypress here and there before (for non-Rails web apps), but it wasn't until we saw your gem that we decided to ditch Capybara and write our Rails app's frontend tests in JS with Cypress help. We've successfully baked the tests into our CD process as well.
With the recent cypress-rails release we can successfully bundle install the project but unfortunately, the tests won't go through on Rails 5 app. Please find the trace attached:
Traceback (most recent call last):
6: from /home/circleci/project/vendor/bundle/gems/cypress-rails-0.1.0/exe/cypress-rails:15:in `<main>'
5: from /home/circleci/project/vendor/bundle/gems/cypress-rails-0.1.0/lib/cypress-rails/run.rb:11:in `call'
4: from /home/circleci/project/vendor/bundle/gems/cypress-rails-0.1.0/lib/cypress-rails/launches_cypress.rb:20:in `call'
3: from /home/circleci/project/vendor/bundle/gems/cypress-rails-0.1.0/lib/cypress-rails/manages_transactions.rb:10:in `begin_transaction'
2: from /home/circleci/project/vendor/bundle/gems/cypress-rails-0.1.0/lib/cypress-rails/manages_transactions.rb:59:in `gather_connections'
1: from /home/circleci/project/vendor/bundle/gems/cypress-rails-0.1.0/lib/cypress-rails/manages_transactions.rb:73:in `setup_shared_connection_pool'
/home/circleci/project/vendor/bundle/gems/activerecord-5.2.4.1/lib/active_record/dynamic_matchers.rb:22:in `method_missing': undefined method `connection_handlers' for ActiveRecord::Base:Class (NoMethodError)
Switching to Rails 6 solves the issue (which we tested on another app).
What is the problem?
connection_handlers method seems to be unavailable in Rails 5. No support for Rails 5 and below is absolutely fine. But it should probably yield an error during bundle install about dependencies that are impossible to meet, not at runtime. I believe it's related to .gemspec file (which is what bundler would look at trying to figure out the dependency net) and that it specifies railties 5.2.0 as a dependency, whereas it should probably say railties 6.0. There is also Gemfile file in the gem's repository that already declares Rails 6 dependency, but I think it's there for other purposes (judging by https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/).
How can this be handled?
Maybe we could simply bump the railties version in the Gemspec? And there turns out to be some gemspec/gemfile confusion we could clear it up too.
I'd be happy to personally contribute back to the project, I'd just need a comment from you before we start any work @searls :D
Hmm, there may be a suitable alternative method or code-path to accomplish the same thing. Before we punt and give up on Rails 5 support, I'd suggest looking at what this file looks like under Rails 5 and see what it's doing differently: https://github.com/rails/rails/blob/master/activerecord/lib/active_record/test_fixtures.rb
If you can find an alternate method call that'll accomplish the same thing under Rails 5, then let's extract a new private method to start that'll branch based on availability of the new method
Aight, I like the branching approach based on the availability of the new method. We'll have a look, thanks!
Actually, support for Rails 5 might actually be simple to implement. Theoretically, only Rails 6 brought multiple databases / replicas support, so on Rails 5 there should just be one connection_handler. And so there is no need for logic that ensures that primary and replica share a connection pool, right?
@eileencodes would be able to answer that more definitively but it sounds like a truthy statement to me
Theoretically, only Rails 6 brought multiple databases / replicas support, so on Rails 5 there should just be one connection_handler. And so there is no need for logic that ensures that primary and replica share a connection pool, right?
Rails 6 introduced multiple connection handlers so calling connection_handlers on any 5 app will raise as you've experienced. Since there can't be a primary/replica on 5.2 or below you can safely assume there's only one connection handler and no need to ensure primary/replica's share a connection.
Awesome. So it sounds like this should be totally feasible then
Just skip this
line for Rails 5.2 and below.Ping @adaRn any luck with this or should I cut a release that bumps the dep to Rails 6?
Can this be applied to < 5.2 ? 🙏
I have a fork with a simple change that works for my case, shall I open a PR? If that's the case, should I bump the version?
Fixed and landed in 0.1.4 ✨
@guillem-catala I kept railties at 5.2 & up. If you can attest that this works for you on a pre-5.2 app, send a PR that sets railties to the version that's working with you and I'll look at it
This issue reoccurs in 0.5.3 ( rails 5.2.6 ActiveRecord::TestFixtures doesn't have setup_shared_connection_pool method )