[APMAPI-1594] (DO-NOT-MERGE) Add support for config inversion on datadog-ci-rb #5256

vpellan · 2026-01-19T16:53:37Z

What does this PR do?

This PR adds support for datadog-ci-rb on config inversion.

Motivation:

We miss all of datadog-ci-rb configs on the config registry

Change log entry

None.

Additional Notes:

DataDog/datadog-ci-rb#459 depends on this PR

How to test the change?

ivoanjo · 2026-01-19T17:07:37Z

lib/datadog/core/configuration/deprecations.rb

+          LOG_DEPRECATIONS_ONLY_ONCE[deprecations] ||= Datadog::Core::Utils::OnlyOnce.new
+          LOG_DEPRECATIONS_ONLY_ONCE[deprecations].run do


Note: The OnlyOnce is designed to be thread safe; when used in this manner it's not going to be thread-safe. I think in practice that's fine (I don't think we need to rely on its thread-safety properties here), but perhaps it's worth leaving a comment along the lines of

# This way of initializing the `OnlyOnce` is not thread-safe but that's OK here LOG_DEPRECATIONS_ONLY_ONCE[deprecations] ||= Datadog::Core::Utils::OnlyOnce.new

datadog-official · 2026-01-19T17:12:49Z

⚠️ Tests

✨ Fix all issues with Cursor

⚠️ Warnings

🧪 1 Test failed

❄️ Known flaky: tests.parametric.test_parametric_endpoints.Test_Parametric_DDTrace_Crash.test_crash[library_env0, parametric-ruby] from system_tests_suite (Datadog) (Fix with Cursor)

assert not True
 +  where True = <bound method ParametricTestClientApi.is_alive of <utils.docker_fixtures._test_clients._test_client_parametric.ParametricTestClientApi object at 0x7fbd14d32840>>()
 +    where <bound method ParametricTestClientApi.is_alive of <utils.docker_fixtures._test_clients._test_client_parametric.ParametricTestClientApi object at 0x7fbd14d32840>> = <utils.docker_fixtures._test_clients._test_client_parametric.ParametricTestClientApi object at 0x7fbd14d32840>.is_alive

self = <tests.parametric.test_parametric_endpoints.Test_Parametric_DDTrace_Crash object at 0x7fbd49775310>
test_library = <utils.docker_fixtures._test_clients._test_client_parametric.ParametricTestClientApi object at 0x7fbd14d32840>

    def test_crash(self, test_library: APMLibrary):
        """Validates that /trace/crash crashes the current process.
    
...

ℹ️ Info

❄️ No new flaky tests detected

🎯 Code Coverage
• Patch Coverage: 88.89%
• Overall Coverage: 95.18% (-0.01%)

View detailed report

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 789eda4 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

pr-commenter · 2026-01-19T17:21:23Z

Benchmarks

Benchmark execution time: 2026-01-21 14:11:50

Comparing candidate commit 789eda4 in PR branch vpellan/config-inversion-datadog-ci-rb with baseline commit b92b5b6 in branch master.

Found 0 performance improvements and 1 performance regressions! Performance is the same for 43 metrics, 2 unstable metrics.

scenario:profiling - gvl benchmark samples

🟥 throughput [-711.067op/s; -700.908op/s] or [-5.351%; -5.274%]

y9v · 2026-01-20T12:27:46Z

lib/datadog/core/configuration/config_helper.rb

        alias_method :member?, :key?

+        # This method will be used by datadog-ci-rb once it will bump its minimum dependancy of dd-trace-rb to 2.27.0.
+        # In the meantime, it uses ConfigHelper#instance_variable_get(:@source_env) to set environment variables.


why this step and not just update to 2.27.0?

I'm curious myself -- I think that's a question for @anmarchenko -- would it be worth doing that bump first there and then coming back to this PR?

I suppose that some customers uses an old version of dd-trace-rb with latest version of datadog-ci-rb and we want to maintain compatibility ? If not then we can indeed skip this step and this should make it easier than trying to maintain compatibility without introducing breaking changes.

datadog-ci-rb once it will bump its minimum dependancy of dd-trace-rb to 2.27.0

I wasn't planning to bump the minimum dependency because I will need then to go other tools that do sanity checks for customer setups (test-visibility-instrumentation-script, ddtest, etc) and adapt the checks to correctly tell the customer which versions we support. This isn't something we plan to invest right now.

In general as much as possible I think we should "push" users to use the latest versions because there's lots of bugs on the old ones AND it creates a big matrix of combinations we don't really test with (any dd-trace-rb x any datadog-ci-rb is a lot of versions...).

But I do think the ultimate owner of this is @anmarchenko so do think it makes sense to leave the decision to him ;)

Yeah, I agree with @ivoanjo, this is what I tried to do as much as possible, but unfortunately life always gets more complicated over time, so this becomes harder when we have more tools that we need to keep in sync.

I would be happy to bump this minimum version for a customer-facing feature that unlocks real value for our customers - then it would a worth endeavour to upgrade for us and the customers. This PR is for internal purposes and we should not make any changes here that might affect customers.

Just to clarify: This PR does not introduce any breaking change to the exisiting codebase of datadog-ci-rb and should not change the behaviour of previously released datadog-ci-rb gems (If someone uses datadog-ci-rb 1.26.0 with dd-trace-rb release that contains these changes, there will be no change in behaviour)

And that is also true for the other way around, if someone uses the version of datadog-ci-rb that contains this PR, it will work with any version of dd-trace-rb that is supported (I've tested with 2.20.0, which doesn't even include config inversion/ConfigHelper code, 2.21.0 which contains the v1 code of config inversion and skip any checks if it detects datadog-ci-rb, and with this PR)

We do not need to bump the dependency of dd-trace-rb on datadog-ci-rb

p-datadog · 2026-01-20T17:21:30Z

lib/datadog/core/configuration/config_helper.rb

        alias_method :include?, :key?
        alias_method :member?, :key?

+        # This method will be used by datadog-ci-rb once it will bump its minimum dependancy of dd-trace-rb to 2.27.0.


Suggested change

# This method will be used by datadog-ci-rb once it will bump its minimum dependancy of dd-trace-rb to 2.27.0.

# This method will be used by datadog-ci-rb after it increases minimum required version of dd-trace-rb to 2.27.0.

p-datadog · 2026-01-20T17:23:58Z

lib/datadog/core/configuration/config_helper.rb

-          # datadog-ci-rb is using dd-trace-rb config DSL, which uses this method.
-          # Until we've correctly implemented support for datadog-ci-rb, we disable config inversion if ci is enabled.
-          if !defined?(::Datadog::CI) &&
+          if (!defined?(::Datadog::CI) || Gem::Version.new(::Datadog::CI::VERSION::STRING) >= Gem::Version.new('1.27.0')) &&


1.27.0 is not released yet, it's a bit sketchy to merge this to our master because if we were to release tomorrow I assume this code will break datadog-ci.

Yes this PR should not be merged until @anmarchenko gives the green light to merge both this PR and DataDog/datadog-ci-rb#459 at the same time. I will change the title of the PR to add "DO-NOT-MERGE"

we should not check for version ever, we must check for capabilities (like specific class present)

because otherwise we will not be able to release datadog-ci gem because CI will be broken

The CI will not be broken but the checks will be skipped. But checking for capabilities is much better because it will not wait for the version to be bumped by fast_castle to actually do the checks, thanks for the feedback!

p-datadog · 2026-01-20T17:26:31Z

lib/datadog/core/configuration/deprecations.rb

      module Deprecations
-        LOG_DEPRECATIONS_ONLY_ONCE = Datadog::Core::Utils::OnlyOnce.new
+        # Hash of OnlyOnce, as we may call log_deprecations_from_all_sources from datadog-ci-rb too with different deprecations set
+        # This way of initializing the `OnlyOnce` is not thread-safe but that's OK here


Yes but this comment goes with the write on line 16, not with the assignment on line 13.

p-datadog · 2026-01-20T17:27:03Z

lib/datadog/core/configuration/deprecations.rb

    module Configuration
      module Deprecations
-        LOG_DEPRECATIONS_ONLY_ONCE = Datadog::Core::Utils::OnlyOnce.new
+        # Hash of OnlyOnce, as we may call log_deprecations_from_all_sources from datadog-ci-rb too with different deprecations set


Suggested change

# Hash of OnlyOnce, as we may call log_deprecations_from_all_sources from datadog-ci-rb too with different deprecations set

# Hash of OnlyOnce instances, as we may call log_deprecations_from_all_sources from datadog-ci-rb too with different deprecations set

The current comment reads as a hash (digest) of a single OnlyOnce instance which is confusing and not what is actually happening.

p-datadog · 2026-01-20T17:28:32Z

lib/datadog/core/configuration/config_helper.rb


+        # This method will be used by datadog-ci-rb once it will bump its minimum dependancy of dd-trace-rb to 2.27.0.
+        # In the meantime, it uses ConfigHelper#instance_variable_get(:@source_env) to set environment variables.
+        def []=(name, value)


I am confused why this method is being added and immediately stated to be unused in the upcoming datadog-ci release, can a comment be added explaining this in more detail please?

datadog-ci-rb is compatible with dd-trace-rb 2.4.0. To make config inversion work on datadog-ci-rb, we monkey-patch DATADOG_ENV, which was introduced in dd-trace-rb 2.21.0 IIRC. For version lower that 2.21.0, DATADOG_ENV will be equal to ENV, but versions above that is a ConfigHelper instance. It is not planned to bump dd-trace-rb dependency in datadog-ci-rb yet, but I added this so it is future proof, and can be used to simplify the code once datadog-ci-rb bumps dd-trace-rb dependency

Add support for config inversion on datadog-ci-rb

ab2dd56

github-actions bot added the core Involves Datadog core libraries label Jan 19, 2026

ivoanjo reviewed Jan 19, 2026

View reviewed changes

vpellan mentioned this pull request Jan 19, 2026

[APMAPI-1594] Config inversion basic implementation DataDog/datadog-ci-rb#459

Open

vpellan added 2 commits January 19, 2026 18:21

Fix failing specs

6c977a1

Add review comment

6724481

vpellan marked this pull request as ready for review January 19, 2026 17:23

vpellan requested a review from a team as a code owner January 19, 2026 17:23

marcotc approved these changes Jan 19, 2026

View reviewed changes

vpellan marked this pull request as draft January 19, 2026 17:30

vpellan added 2 commits January 19, 2026 18:30

lint

dc53049

Add ConfigHelper#[]= method

c9e1eb7

vpellan marked this pull request as ready for review January 20, 2026 11:49

y9v reviewed Jan 20, 2026

View reviewed changes

p-datadog reviewed Jan 20, 2026

View reviewed changes

vpellan requested a review from anmarchenko January 21, 2026 10:08

vpellan changed the title ~~[APMAPI-1594] Add support for config inversion on datadog-ci-rb~~ [APMAPI-1594] (DO-NOT-MERGE) Add support for config inversion on datadog-ci-rb Jan 21, 2026

Apply suggestions

789eda4

		LOG_DEPRECATIONS_ONLY_ONCE[deprecations] \|\|= Datadog::Core::Utils::OnlyOnce.new
		LOG_DEPRECATIONS_ONLY_ONCE[deprecations].run do

	# This method will be used by datadog-ci-rb once it will bump its minimum dependancy of dd-trace-rb to 2.27.0.
	# This method will be used by datadog-ci-rb after it increases minimum required version of dd-trace-rb to 2.27.0.

	# Hash of OnlyOnce, as we may call log_deprecations_from_all_sources from datadog-ci-rb too with different deprecations set
	# Hash of OnlyOnce instances, as we may call log_deprecations_from_all_sources from datadog-ci-rb too with different deprecations set

[APMAPI-1594] (DO-NOT-MERGE) Add support for config inversion on datadog-ci-rb #5256

Are you sure you want to change the base?

[APMAPI-1594] (DO-NOT-MERGE) Add support for config inversion on datadog-ci-rb #5256

Conversation

vpellan commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

datadog-official bot commented Jan 19, 2026 • edited by datadog-datadog-prod-us1 bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Warnings

ℹ️ Info

Uh oh!

pr-commenter bot commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

scenario:profiling - gvl benchmark samples

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anmarchenko Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

vpellan commented Jan 19, 2026 •

edited

Loading

datadog-official bot commented Jan 19, 2026 •

edited by datadog-datadog-prod-us1 bot

Loading

pr-commenter bot commented Jan 19, 2026 •

edited

Loading

anmarchenko Jan 21, 2026 •

edited

Loading