-
Notifications
You must be signed in to change notification settings - Fork 375
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
Rails 6 support #814
Rails 6 support #814
Conversation
def datadog_parse_args(view, template, layout_name, *args) | ||
[template, layout_name] | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After many iterations, I ended up with separate modules to encapsulate this branching logic between Rails v3.1-v5 and v6.
The reason I chose this approach in end was because:
- It makes it clear to us which implementation is the latest, without explicit branching logic.
- This allows for easier deprecation of older implementations in the future.
- It avoids conditional branching at runtime, making such decision during our patching phase.
I did add a method call, so the overhead of this approach is not zero.
In the end, I valued how clearly Rails 6 and future versions will read over succinctness of changes (few lines touched), as my best judgement here is that this approach increases maintainability.
Regardless of my rationale, I'm very much open to suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to give this a more thorough review later, but I like what I see so far! One minor comment related to tests on the first scan.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good! Just want to request some relatively small housekeeping tasks, but otherwise very pleased with this.
require 'contrib/rails/apps/application' | ||
|
||
module Rails6 | ||
class Application < RailsTrace::TestApplication |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This Application
class is defined as a full-blown constant (as opposed to some kind of stub) because of how we setup Minitest to test Rails yeah? I don't think there's anything else to do here, just wanted to clarify that's the case, which would mean this will go away when we finish migrating to RSpec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is correct!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one suggestion about naming, otherwise this is ready.
module Datadog | ||
module Contrib | ||
module ActionView | ||
module Instrumentations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick but I think it should be Instrumentation
singular.
cd56ee7
to
a28279c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks @marcotc! 👍
Add support for all Rails tracer features to Rails 6.
Compared to Rails 5, there are not new features in Rails 6 that require special instrumentation for enhanced visibility.
One example is support for multiple databases: the infrastructure was already present in its current form since Rails 5.
Also, a few notable changes to our testing infrastructure:
contrib
Rails tests now run on Rails 6.sqlite3
version to1.4
: Rails 6 requires it and our reason to lock it to1.3
doesn't hold anymore as Rails has released new versions that are compatible withsqlite3
1.4
.Active*/Action*
gems) before application initialization by loading only routesroutes
first, and loadingcontrollers
after initialization. This is recommended for Rails 6 with its new autoloader, zeitwerk, and will be mandatory in a future version.