DI progress logs #4283
DI progress logs #4283
Conversation
|
👋 Hey @p-datadog, please fill "Change log entry" section in the pull request description. If changes need to be present in CHANGELOG.md you can state it this way **Change log entry**
Yes. A brief summary to be placed into the CHANGELOG.md(possible answers Yes/Yep/Yeah) Or you can opt out like that **Change log entry**
None.(possible answers No/Nope/None) Visited at: 2025-01-14 16:40:36 UTC |
Datadog ReportBranch report: ❌ 37 Failed (0 Known Flaky), 21910 Passed, 1476 Skipped, 6m 0.48s Total Time ❌ Failed Tests (37)
|
lib/datadog/di.rb
Outdated
| if %w'1 true debug'.include?(ENV['DD_TRACE_DEBUG']) | ||
| # We seem to have Datadog.logger here already | ||
| Datadog.logger.debug("di: activating code tracking") | ||
| end |
There was a problem hiding this comment.
I'm not sure the DD_TRACE_DEBUG check is needed -- the logger initialization is already supposed to be looking at this setting? https://github.com/DataDog/dd-trace-rb/blob/master/lib/datadog/core/configuration.rb#L279 and https://github.com/DataDog/dd-trace-rb/blob/master/lib/datadog/core/configuration/components.rb#L37 should take care of it.
p-datadog
force-pushed
the
di-progress-logs
branch
from
73b4959 to
baa571f
Compare
p-datadog
force-pushed
the
di-progress-logs
branch
from
baa571f to
01eef0d
Compare
Datadog ReportBranch report: ❌ 49 Failed (0 Known Flaky), 22012 Passed, 1476 Skipped, 7m 30.98s Total Time ❌ Failed Tests (49)
|
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
| @@ -45,6 +45,7 @@ def initialize(settings, transport, logger, telemetry: nil) | |||
|
|
|||
| def start | |||
| return if @thread | |||
| logger.debug("di: starting probe notifier: pid #{$$}") | |||
There was a problem hiding this comment.
⚪ Code Quality Violation
Avoid using cryptic PERL names. Consider importing English and using $PROCESS_ID instead. (...read more)
The rule 'Avoid using Perl-style special variables' is important for improving the readability and maintainability of your code. Perl-style special variables, such as $0, $1, and $_, while powerful, can make your code less readable and harder to understand, especially for developers unfamiliar with Perl or its influence on Ruby. They can also introduce subtle bugs due to their global nature and the special behavior associated with them.
To avoid violating this rule, you can use the more descriptive aliases provided by the English library. This library, which is part of Ruby's standard library, provides human-readable names for Perl-style special variables. For example, instead of using $& to get the string matched by the last successful pattern match, you can use $MATCH.
Here's a compliant code example: Instead of $_, you can use $LAST_READ_LINE. Instead of $!, use $ERROR_INFO. This makes your code more self-explanatory and reduces the potential for confusion. Example:
require 'English'
puts $LAST_READ_LINE
puts $ERROR_INFOThis practice significantly enhances the readability of your code and makes it more accessible to developers who are not familiar with Perl-style variables.
p-datadog
force-pushed
the
di-progress-logs
branch
from
d25a59a to
607ad2b
Compare
| @@ -17,6 +17,9 @@ module DI | |||
| class Component | |||
| class << self | |||
| def build(settings, agent_settings, logger, telemetry: nil) | |||
| logger = Logger.new(STDERR, progname: "\033[7mdatadog/di\e[0m") | |||
There was a problem hiding this comment.
⚪ Code Quality Violation
| logger = Logger.new(STDERR, progname: "\033[7mdatadog/di\e[0m") | |
| logger = Logger.new($stderr, progname: "\033[7mdatadog/di\e[0m") |
Consider using a $stderr (...read more)
The rule "Avoid standard constants" is important in Ruby development as it encourages the use of global variables over standard constants. In Ruby, standard constants like STDOUT and STDERR are not as flexible as their global counterparts $stdout and $stderr.
The main reason for avoiding standard constants is that they are not interchangeable in the same way that global variables are. This means they are less suited to situations where you might need to redirect output or error streams. For instance, in testing scenarios, you might want to redirect $stdout or $stderr to a different output stream.
Fortunately, Ruby provides an easy way to avoid this issue. Instead of using standard constants, you should use global variables. For example, replace STDOUT with $stdout and STDERR with $stderr. This allows for greater flexibility in your code and makes it more adaptable to different situations.
| @@ -94,6 +95,7 @@ def start | |||
| # to killing the thread using Thread#kill. | |||
| def stop(timeout = 1) | |||
| @stop_requested = true | |||
| logger.debug("di: stopping probe notifier: pid #{$$}") | |||
There was a problem hiding this comment.
⚪ Code Quality Violation
Avoid using cryptic PERL names. Consider importing English and using $PROCESS_ID instead. (...read more)
The rule 'Avoid using Perl-style special variables' is important for improving the readability and maintainability of your code. Perl-style special variables, such as $0, $1, and $_, while powerful, can make your code less readable and harder to understand, especially for developers unfamiliar with Perl or its influence on Ruby. They can also introduce subtle bugs due to their global nature and the special behavior associated with them.
To avoid violating this rule, you can use the more descriptive aliases provided by the English library. This library, which is part of Ruby's standard library, provides human-readable names for Perl-style special variables. For example, instead of using $& to get the string matched by the last successful pattern match, you can use $MATCH.
Here's a compliant code example: Instead of $_, you can use $LAST_READ_LINE. Instead of $!, use $ERROR_INFO. This makes your code more self-explanatory and reduces the potential for confusion. Example:
require 'English'
puts $LAST_READ_LINE
puts $ERROR_INFOThis practice significantly enhances the readability of your code and makes it more accessible to developers who are not familiar with Perl-style variables.
What does this PR do?
Motivation:
Change log entry
Additional Notes:
How to test the change?