Why is cache_classes conditioned on environment variable?

[drewguild]

Installing CypressOnRails will change cache_classes=true to cache_classes=ENV['CI'].present?. What is the reason for deriving this value from the presence of that environment variable? I assume the idea is to get different behavior between local development and running the suite on a CI server. Not sure I understand why one would want that. Any insight is appreciated!

[grantspeelman]

Good question @drewguild

yes, your assumption is right about having different behavior between your local and on CI.

When I initially started writing cypress tests I would start the server using the test environment so it would not overwrite my development database. As you would see in the README.md

So because of that, in order to not have to restart the server every time I make a change to the code, cache_classes would have to be set to false.

So that is how it has become the default 😄

[grantspeelman]

That all said, we don't do it like that anymore and instead on our local, we start the server in development and change which database gets used, using an environment variable.

DB_DATABASE=cypress_db CYPRESS=1 bin/rails s -p 5017 -P tmp/cypress.pid

We still use the test environment on CI but no longer need to disable cache_classes based on CI.

We handlle the CI difference now inside the cypress_on_rails,rb initializer

if defined?(CypressOnRails)
  CypressOnRails.configure do |c|
    c.cypress_folder = File.expand_path("#{__dir__}/../../cypress")
    c.use_middleware = !Rails.env.production?
    c.logger = Rails.logger
  end

  if ENV['CI'].present?
    Rails.application.configure do
      config.assets.compile = false
      config.assets.unknown_asset_fallback = false
      config.active_job.queue_adapter = :async
    end
  end
end

This could maybe be a better default?

[yagudaev]

interesting, why we actually have a separate environment we created called cypress_dev for just that use case. I really don't like it tho as it doesn't get db:migrate updates automatically. So your solution is much better there.

Perhaps instead of specifying the DB name directly, CYPRESS=1 would be enough. So you can run:

CYPRESS=1 bin/rails s -p 5017 -P tmp/cypress.pid

and

CYPRESS=1 bin/rails c

For debugging.

I would probably also hide the whole string behind a small script like bin/cypress_on_rails start.

Thinking about it further, we could even do some shell script magic and get all rails commands to work with it and add additional commands that are cypress specific.

# alias all `rails [command]` specific to cypress on rails env
bin/cypress_on_rails s # rails server
bin/cypress_on_rails c # rails console

# alias all `yarn run cypress [command]`
bin/cypress open # yarn cypress open
bin/cypress run  # yarn cypress run