DDEV Validate DEP: Always set repo_choice if check_root is true

[ddog-nasirthomas]

What does this PR do?

When check_root() was true, the repo_choice would never get set for the application config. initialize_root returns immediately when check_root() is true, so it never runs the code that sets config['repo_choice']

This PR makes sure that repo_choice is set even if check_root() is true.

Motivation

Issue found when working through this PR: #23584

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add the qa/skip-qa label if the PR doesn't need to be tested during QA.
• If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

[ddog-nasirthomas]

Didn't add a changelog, but let me know if it's needed

[dd-octo-sts]

Validation Report

All 20 validations passed.

Show details

Validation	Description	Status
agent-reqs	Verify check versions match the Agent requirements file	✅
ci	Validate CI configuration and Codecov settings	✅
codeowners	Validate every integration has a CODEOWNERS entry	✅
config	Validate default configuration files against spec.yaml	✅
dep	Verify dependency pins are consistent and Agent-compatible	✅
http	Validate integrations use the HTTP wrapper correctly	✅
imports	Validate check imports do not use deprecated modules	✅
integration-style	Validate check code style conventions	✅
jmx-metrics	Validate JMX metrics definition files and config	✅
labeler	Validate PR labeler config matches integration directories	✅
legacy-signature	Validate no integration uses the legacy Agent check signature	✅
license-headers	Validate Python files have proper license headers	✅
licenses	Validate third-party license attribution list	✅
metadata	Validate metadata.csv metric definitions	✅
models	Validate configuration data models match spec.yaml	✅
openmetrics	Validate OpenMetrics integrations disable the metric limit	✅
package	Validate Python package metadata and naming	✅
readmes	Validate README files have required sections	✅
saved-views	Validate saved view JSON file structure and fields	✅
version	Validate version consistency between package and changelog	✅

View full run

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.04%. Comparing base (e529a0b) to head (88a7809).

Additional details and impacted files

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[datadog-prod-us1-4]

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 65.25% (-21.99%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 88a7809 | Docs | Datadog PR Page | Give us feedback!}

[AAraKKe]

Hi @ddog-nasirthomas!

Thanks for opening this and for digging into the failure.

I do not think this is the direction we want to take, though. The standard ddev path already resolves the active repo before commands run, through app.repo. That repo is selected from flags, config, env vars, and local overrides. The datadog_checks_dev repo-selection logic is legacy behavior from before the migration, and I do not think we should keep expanding it. Commands should use app.repo as the source of truth instead of re-deriving repo identity from legacy globals like get_root() or from directory names.

The issue with this PR is that it makes initialize_root() infer repo_choice from the root path basename when check_root() is already true. That can work in a narrow case, but it adds another repo-detection path to an area that is already confusing. It is also brittle because it depends on the local checkout directory name. If someone clones integrations-core into a directory with a different name, the proposed logic can infer the wrong repo. It can also be wrong if the old global root is stale or if ddev has already selected a different repo through -e, -m, DDEV_REPO, config, or local overrides.

If this came from a validation failure, I think the better fix is to update that validation to use the repo already selected by ddev. Checks-dev commands that run through the ddev entrypoint receive the Application object as ctx.obj, so they can read the active repo directly:

app = ctx.obj
repo_name = app.repo.name
repo_path = app.repo.path
repo_full_name = app.repo.full_name

For example, a validation that needs to know whether it is running against integrations-core should check:

is_core = ctx.obj.repo.name == "core"

instead of depending on ctx.obj["repo_choice"] or trying to infer the repo from get_root() / the directory name.

There are still legacy datadog_checks_dev commands that are not fully migrated, and some commands invoke other commands internally. That is part of the problem we need to clean up. If one of those paths still needs to support both the old checks-dev context shape and the new ddev Application context, I would rather handle that explicitly in the command or migrate the command than add another repo detection path based on directory names.

If this is not currently blocking work, I would prefer to wait for the migration instead of adding more behavior to the legacy initialization path.

[ddog-nasirthomas]

Hi @AAraKKe

For some reason, I can’t reply directly under your comment.

The logic you described makes sense. In that case, I agree it’s better to use the repo selected by ddev via the application object, we don’t really need repo_choice here. In my other PR, I initially considered using ctx.obj.repo.name, but choosing how to reference the repo was a bit confusing given the number of options.

I’ll probably close this PR since there’s no work needed here.