chore(civis): move configurations to envier

[mabdinur]

Motivation

• Increase the adoption of envier in ddtrace products
• Remove product specific configurations from the global config object

Changes

• Moves newly added ci_visibility_log_level and test_session_name configurations from ddtrace.config to ddtrace.settings.civis.ci_config and ddtrace.settings.civis.test_config. Since support for ci_visibility_log_level and test_session_name is unreleased this is not a breaking change.
• Moves all civis related attributes from ddtrace.config (the remaining configs are internal so this is not a breaking change)

Checklist

• PR author has checked that all the criteria below are met
• The PR description includes an overview of the change
• The PR description articulates the motivation for the change
• The change includes tests OR the PR description describes a testing strategy
• The PR description notes risks associated with the change, if any
• Newly-added code is easy to change
• The change follows the library release note guidelines
• The change includes or references documentation updates if necessary
• Backport labels are set (if applicable)

Reviewer Checklist

• Reviewer has checked that all the criteria below are met
• Title is accurate
• All changes are related to the pull request's stated goal
• Avoids breaking API changes
• Testing strategy adequately addresses listed risks
• Newly-added code is easy to change
• Release note makes sense to a user of the library
• If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
• Backport labels are set in a manner that is consistent with the release branch maintenance policy

[github-actions]

CODEOWNERS have been resolved as:

ddtrace/settings/civis.py                                               @DataDog/ci-app-libraries
.github/CODEOWNERS                                                      @DataDog/python-guild @DataDog/apm-core-python
ddtrace/internal/ci_visibility/recorder.py                              @DataDog/ci-app-libraries
ddtrace/internal/ci_visibility/utils.py                                 @DataDog/ci-app-libraries
ddtrace/internal/ci_visibility/writer.py                                @DataDog/ci-app-libraries
ddtrace/internal/telemetry/writer.py                                    @DataDog/apm-core-python
ddtrace/settings/config.py                                              @DataDog/python-guild @DataDog/apm-sdk-api-python
tests/ci_visibility/api_client/test_ci_visibility_api_client.py         @DataDog/ci-app-libraries
tests/ci_visibility/test_ci_visibility.py                               @DataDog/ci-app-libraries
tests/ci_visibility/util.py                                             @DataDog/ci-app-libraries
tests/telemetry/test_writer.py                                          @DataDog/apm-core-python
tests/utils.py                                                          @DataDog/python-guild

[datadog-dd-trace-py-rkomorn]

Datadog Report

Branch report: munir/use-envier-for-civis
Commit report: 2c5c483
Test service: dd-trace-py

✅ 0 Failed, 1286 Passed, 0 Skipped, 13m 23.17s Total Time

[mabdinur]

TODO: fix how ci_vis configurations are mocked in tests

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-10-09 06:35:11

Comparing candidate commit 2c5c483 in PR branch munir/use-envier-for-civis with baseline commit 0bf1fe9 in branch main.

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

scenario:span-start

• 🟩 max_rss_usage [-4.748MB; -4.652MB] or [-11.807%; -11.569%]

[P403n1x87]

what's the underscore for?

[mabdinur]

I want to keep this attriubte "internal" to keep things consistent with how this confiuration was previously defined. Not sure if this is the right approach

[P403n1x87]

If the corresponding env var is "private" (i.e. has a _ prefix, then it should have the private=True kwarg (e.g.

dd-trace-py/ddtrace/settings/symbol_db.py

Line 32 in f757fbf

private=True,

). Then I think it's fine to keep the _ in here as well

[P403n1x87]

These could be grouped in a nested sub-class