Skip to content

Fix regression mailer preview path #1388

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jun 5, 2015

Conversation

cupakromer
Copy link
Member

This fixes the regression where setting the ActionMailer preview path leaked into versions which does not support it (Rails before 4.1).

The cause of the regression was a series of failures:

  • The integration spec did not force ActionMailer::Base to load; thus the incorrect setting was not loaded exposing the issue
  • In the case of older Rails versions, it was believed that the mailer spec's script defaulting to the "development" environment would be sufficient. However, when shelling out the existing Ruby ENV was already available, resulting in the RAILS_ENV already being set to "test". Thus the test was not explicitly testing the code as expected.
  • The implementation code itself made a note about config.action_mailer.show_previews always returning true, yet code slightly further down was relying on config.action_mailer.preview_path being able to return false (which it never will)

This fixes each of these issues.

Based on minimal local testing it appears that defined?(ActionMailer), while possibly loading ActionMailer, will not force the configuration to load. The configuration is only with ActionMailer::Base.

I'm weary 😩 about switching out the logic yet again regarding: defined?(ActionMailer) vs config.respond_to?(:action_mailer). It's possible that on any further version the behavior of the config being loaded or the config changing to always respond true can occur. For now, it seems that config.respond_to?(:action_mailer) is working and stable. Though I'm always open to further discussion.

Resolve #1386

/cc @tagliala, @olance, @myronmarston

This fixes the spec suite to expose issues with `ActionMailer` being
configured incorrectly when previews are not available.

This addresses several issues:

- The incorrect configuration options are only exposed once
  `ActionMailer::Base` is loaded; this forces the class to load in the
  mailer initializer and at the end of our script
- This adds specs specifically for the "development" environment which
  were missing before; it appeared that by not setting the environment
  it would default to "development" per the script, however, when the
  command shells out the `RAILS_ENV` is already set to "test" from rspec
  running.

  To be certain we cover the other possible edge cases we specifically
  add more tests for `ActionMailer` not being available, and for a
  custom configuration being set after `rspec-rails` is loaded.
- Despite us asking Rails to turn off eager loading in our custom
  script, several files were still getting eager loaded; this
  explicitly clears the eager load paths to stop this
- This fixes how the mailer script is shelled out in Ruby 1.8.7; now the
  environment variables are properly formatted and standard error is
  piped to standard out

Exposes the regression issue in #1386
The `preview_path` feature of `ActionMailer` was added in Rails 4.1.
Versions before that release are not able to handle that configuration.
The regression issue occurred in part to the spec suite overlooking
changes to the environment and how that affects the shelling out.

Additionally, the previous changes noted that the configuration for a
particular module always responds to a setting; even when it should not.
However, while this logic was noted for `show_previews`, a few lines
further down, that same logic was overlooked for `preview_path`.

It appears the only available methods for detecting `ActionMailer`, and
it's features, is tasting the top-level `config` in addition to checking
the Rails version string.

if defined?(ActionMailer)
# This will force the loading of ActionMailer settings
ActionMailer::Base.smtp_settings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the same on all versions of Rails?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can tell.

Provide a more accurate description of the behavior we are avoiding and
why the current behavior is used.

[ci skip]
else
Rails.application.configure do
config.action_mailer.default_url_options = { :host => ENV['DEFAULT_URL'] }
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious why this change is related to this PR? Shouldn't we always have been doing this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it should always have been there. Rails changed how they provided access to the configuration in 4.1. Incidentally the mailer specs / script never executed with a code path testing a default url option on Rails < 4.1. Which is also partially related to why this issue wasn't noticed sooner.

After fixing the mailer specs to run better coverage for Rails < 4.1, reproducing the issue, more things started failing as this code path was actually run. Thus, a fix is included here. The commit 9522842 has a long explanation of several related things which got fixed in the spec suite.

@myronmarston
Copy link
Member

Thanks for getting on this promptly, @cupakromer. I'm happy to defer to @JonRowe's review since I don't really have the context for this.

JonRowe added a commit that referenced this pull request Jun 5, 2015
@JonRowe JonRowe merged commit e9fb455 into master Jun 5, 2015
@JonRowe JonRowe deleted the fix-regression-mailer-preview-path branch June 5, 2015 05:48
@JonRowe
Copy link
Member

JonRowe commented Jun 5, 2015

Looks all good to me

@olance
Copy link

olance commented Jun 5, 2015

👍

@myronmarston
Copy link
Member

@cupakromer Are you planning to work up a 3-2-maintenance backport for this?

@cupakromer
Copy link
Member Author

@myronmarston done: #1389

Just waiting for the sanity check to go green.

cupakromer added a commit that referenced this pull request Jun 5, 2015
Back port pull request #1388 from rspec/fix-regression-mailer-preview-path
@chrisbloom7
Copy link

FYI Currently blocked on upgrading a Rails 4.0 app to use Ruby 2.2. This bug is preventing me from upgrading to rspec-rails 3.2, but issue #1273 (recommended solution: upgrade to 3.2) prevents the suite from running on rspec-rails 3.1

@myronmarston
Copy link
Member

@chrisbloom7 -- I released rspec-rails 3.2.3 with a fix for this yesterday, so you should be able to upgrade now.

@chrisbloom7
Copy link

@myronmarston Thanks, everything is green on Rails 4.0, rspec-rails 3.2.2, and Ruby 2.2.2

@bquorning bquorning mentioned this pull request Mar 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rails 3.2.1 does not start with rspec-rails 3.2.2
5 participants