Enable crashtracking without profiler #3826
Conversation
github-actions
bot
added
core
BenchmarksBenchmark execution time: 2024-08-15 10:38:12 Comparing candidate commit 6f3c5fe in PR branch Found 0 performance improvements and 4 performance regressions! Performance is the same for 19 metrics, 2 unstable metrics. scenario:profiler - Allocations ()
scenario:profiler - Allocations (profiling disabled)
scenario:profiler - Allocations (profiling enabled)
scenario:profiler - sample timeline=false
|
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3826 +/- ##
==========================================
+ Coverage 97.83% 97.84% +0.01%
==========================================
Files 1264 1269 +5
Lines 75725 75869 +144
Branches 3729 3736 +7
==========================================
+ Hits 74084 74233 +149
+ Misses 1641 1636 -5 ☔ View full report in Codecov by Sentry. |
TonyCTHsu
force-pushed
the
tonycthsu/crashtracking
branch
3 times, most recently
from
c7defa4
to
c59c4f3
Compare
TonyCTHsu
force-pushed
the
tonycthsu/crashtracking
branch
from
3ada1aa
to
6cb7c4c
Compare
| end | ||
| end | ||
|
|
||
| def build_crashtracker(options = {}) |
There was a problem hiding this comment.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
|
|
||
| let(:agent_base_url) { "http://#{hostname}:#{port}" } | ||
|
|
||
| [:fiddle, :signal].each do |trigger| |
There was a problem hiding this comment.
⚪ Code Quality Violation
| [:fiddle, :signal].each do |trigger| | |
| %i[fiddle signal].each do |trigger| |
Consider using the %i syntax instead (...read more)
The rule "Prefer %i to the literal array syntax" is a guideline that encourages the use of the %i syntax for arrays of symbols. This is a part of the Ruby style guide that aims to promote conciseness and readability.
Symbols are immutable, reusable objects often used in Ruby instead of strings when the value does not need to be changed. When declaring an array of symbols, using the %i syntax can make your code cleaner and easier to read.
To adhere to this rule, instead of declaring an array of symbols using the literal array syntax like [:foo, :bar, :baz], use the %i syntax like %i[foo bar baz]. It's a good practice to consistently use %i for arrays of symbols as it enhances code readability and maintainability.
TonyCTHsu
force-pushed
the
tonycthsu/crashtracking
branch
from
0d915c6
to
11ee87c
Compare
TonyCTHsu
force-pushed
the
tonycthsu/crashtracking
branch
from
11ee87c
to
6f3c5fe
Compare
| datadog_gem_path = versioned_path.join("gems/datadog-#{ENV.fetch('RUBY_PACKAGE_VERSION')}") | ||
| libdatadog_so_file = "libdatadog_api.#{RUBY_VERSION[/\d+.\d+/]}_#{RUBY_PLATFORM}.so" | ||
| unless File.exist?("#{datadog_gem_path}/lib/#{libdatadog_so_file}") | ||
| raise "Missing #{libdatadog_so_file} in #{datadog_gem_path}." | ||
| end |
There was a problem hiding this comment.
You can also get this check by setting the DD_FAIL_INSTALL_IF_MISSING_EXTENSION env variable to "true" when calling gem install :)
| 'version' => settings.version, | ||
| 'git.repository_url' => Environment::Git.git_repository_url, | ||
| 'git.commit.sha' => Environment::Git.git_commit_sha, | ||
| 'is_crash' => true |
There was a problem hiding this comment.
Nice catch! I was talking with @sanchda about this yesterday and he mentioned libdatadog wasn't adding these automatically.
In Python we also add severity:crash (see DataDog/dd-trace-py#10199 ). I was planning on doing a PR to add this one as well, but in case you want to go ahead ;)
What does this PR do?
This PR extracts crash tracking capabilities from profiler. This means crash tracking could be enabled without profiler.