Unify ddev workflow installs with uv cache

[AAraKKe]

What does this PR do?

Adds .github/actions/setup-ddev as the shared install path for workflows that need ddev.

The action validates its supported inputs up front: install-mode can be local or pypi, and cache-profile can be local-ddev-base or local-ddev for local installs. It installs uv with the setup-uv cache disabled, restores the shared uv and pip cache explicitly, installs ddev, then saves a warmed cache when the exact daily cache key was not already present.

For local integrations-core installs, the action installs editable datadog_checks_dev[cli] and ddev from the checkout. The default local-ddev-base cache profile keys the cache on the Python location plus the datadog_checks_base, datadog_checks_dev, and ddev pyproject files. The local-ddev profile is available for jobs that only need the datadog_checks_dev and ddev dependency set.

For non-core reusable workflow callers, the action uses install-mode: pypi and installs ddev from PyPI. Those jobs restore and save a separate PyPI cache namespace keyed by Python location, requested ddev version, and the daily cache suffix.

The cache restore order is exact daily key first, then a same-dependency daily prefix, then the previous non-daily key shape, then a broader same-Python fallback. This lets jobs reuse existing caches while also letting the first job of the day refresh the restored cache after uv pip install downloads any missing artifacts.

Core workflows that install ddev now call this action directly. Reusable workflows that can run from integrations-extras or marketplace still check out integrations-core into core-temp and call ./core-temp/.github/actions/setup-ddev, so the composite action does not need to exist in the caller repository.

Motivation

Several workflows installed ddev with plain pip or carried their own uv/cache setup. That made installs slower and made it easy for workflows with the same dependency set to use different cache keys.

Centralizing the setup gives all core ddev installs the same cache behavior and makes the cache self-warming from the install action itself, instead of relying only on a separate warmer workflow.

This is non-breaking for integrations-extras and marketplace because this PR only changes integrations-core. Workflows in those repositories that install ddev directly are untouched until those repositories are changed. For reusable workflows invoked from integrations-core, non-core callers use the core-temp checkout path and PyPI install mode, so they do not need the new composite action in their own repositories. The cache restore keys also keep the previous cache key shape as a fallback, so existing caches remain reusable while new daily caches are populated.

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 does not 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

Validation

• Parsed the edited workflow/action YAML files with Ruby YAML.load_file.
• Ran git diff --check.
• Searched workflows to confirm no direct pip install ... ddev remains.
• actionlint was not available locally.

[datadog-prod-us1-5]

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 87.36% (+0.13%)

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.84%. Comparing base (eee337d) to head (8e9901f).
⚠️ Report is 6 commits behind head on master.

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.

[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