-
Notifications
You must be signed in to change notification settings - Fork 392
Add integration test suite #1305
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
Conversation
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.
Thanks a lot for this, it will be mega useful :)
I wonder if it's worth leaving a TODO/FIXME to add a check for Ruby 2.0. Just so it's less hard to get surprised by something weird/broken there.
integration/apps/rails-six/config/initializers/application_controller_renderer.rb
Outdated
Show resolved
Hide resolved
4634b1b
to
b58f4f2
Compare
Codecov Report
@@ Coverage Diff @@
## master #1305 +/- ##
=======================================
Coverage 98.13% 98.13%
=======================================
Files 752 752
Lines 35745 35745
=======================================
+ Hits 35078 35079 +1
+ Misses 667 666 -1
Continue to review full report at Codecov.
|
b8b14ed
to
a56049a
Compare
555167e
to
07d1c5a
Compare
Removed |
440b458
to
809b5d5
Compare
All feedback should be addressed. I also cleaned up the history, trimmed out a bunch of files we're not using in this PR, and got the build mostly working. Still one outstanding problem with Ruby 2.3: has a missing binary that should be there after gems are installed. I think for some reason the gems aren't being installed to Otherwise, this is ready for another round of code reviews. Should be a lot cleaner and easier to read this time around. |
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.
Looking really nice! Left a bunch of small notes, but overall it's almost good to go :)
# NOTE: Disabled for now, suspected to cause memory growth. | ||
# Fetch from cache | ||
# Rails.cache.fetch(request_id) { request_id } |
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.
Interesting... Can you add a bit more context here?
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.
I think because each request ID is unique, and fetch
gets or adds the request ID to the cache, it will grow indefinitely. This was added as a cheap way of implementing cache usage (for showing in traces) but it probably doesn't need to create this many keys.
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.
Your explanation makes some sense :)
May I suggest adding it as a comment? That would be a good starting point if someone ran into this and was also wondering what was the problematic effect.
|
||
before_fork do | ||
ActiveRecord::Base.connection_pool.disconnect! | ||
#$redis.pool_shutdown { |conn| conn.quit } |
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.
I'm curious about this one, could you add a bit more detail?
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.
I don't remember on this one... not sure if it was disabled for testing or if it was causing problems with restarting traces (e.g. conn.quit
might be instrumented, which generates a span, which has to be emitted.)
b67b240
to
fccdcf8
Compare
db5ebd0
to
9d46a61
Compare
9d46a61
to
b934675
Compare
docker build -t datadog/dd-apm-demo:rb-2.0 -f $INTEGRATION_DIR/images/ruby/2.0/Dockerfile $INTEGRATION_DIR/images | ||
docker build -t datadog/dd-apm-demo:rb-2.1 -f $INTEGRATION_DIR/images/ruby/2.1/Dockerfile $INTEGRATION_DIR/images | ||
docker build -t datadog/dd-apm-demo:rb-2.2 -f $INTEGRATION_DIR/images/ruby/2.2/Dockerfile $INTEGRATION_DIR/images | ||
docker build -t datadog/dd-apm-demo:rb-2.3 -f $INTEGRATION_DIR/images/ruby/2.3/Dockerfile $INTEGRATION_DIR/images | ||
docker build -t datadog/dd-apm-demo:rb-2.4 -f $INTEGRATION_DIR/images/ruby/2.4/Dockerfile $INTEGRATION_DIR/images | ||
docker build -t datadog/dd-apm-demo:rb-2.5 -f $INTEGRATION_DIR/images/ruby/2.5/Dockerfile $INTEGRATION_DIR/images | ||
docker build -t datadog/dd-apm-demo:rb-2.6 -f $INTEGRATION_DIR/images/ruby/2.6/Dockerfile $INTEGRATION_DIR/images | ||
docker build -t datadog/dd-apm-demo:rb-2.7 -f $INTEGRATION_DIR/images/ruby/2.7/Dockerfile $INTEGRATION_DIR/images | ||
docker build -t datadog/dd-apm-demo:rb-3.0 -f $INTEGRATION_DIR/images/ruby/3.0/Dockerfile $INTEGRATION_DIR/images |
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.
Minor: It occurs to me that we could start leaving a comment like # SUPPORTED_RUBIES_UPDATE_HERE
on every place in the codebase that would need to be touched e.g. once we drop support for 2.0 or once 3.1 gets released.
That way we could easily grep for that string whenever we're doing changes, and thus be reasonably sure we touched all the right places, rather than trying to grep 3.0
and 2.0
and hope we haven't missed anything :)
What do you think?
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.
Yeah I do like a directive like that; would aid refactoring. Maybe that's a mini-RFC we should do for this application in general. Let's discuss with the rest of the Ruby team.
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.
🎉 I think this new test suite will greatly improve our confidence when introducing changes to the tracer. 🙇
Goal for this pull request is to introduce an integration test suite that can run real applications (via Docker images) to test the
ddtrace
library. These tests will focus on stability ("will the application load & function?") and correctness ("do they produce the expected APM data?")These tests should be available to run locally, and will automatically run via CircleCI upon a pull request or merge.
TODO:
integration/apps/rack
,integrations/apps/rails-five
)Add additional test apps, e.g. Rails 6, Sinatra, Ruby (stretch goal)