Tooling

The build, lint, codegen, and developer tools that wrap the Datadog Agent.

dda — the developer CLI

Almost everything goes through dda:

brew install --cask dda          # macOS
# Linux/Windows: see https://datadoghq.dev/dda/

dda inv … is shorthand for "invoke a task in tasks/." Configuration for dda itself lives in .dda/.

dda inv install-tools            # Install Go, mockery, etc. pinned by the repo
dda inv --list                   # All available tasks

Invoke task catalog

tasks/ is, in effect, the human-facing interface to this repository's tooling. Major modules:

Module	Purpose	Examples
agent.py	Build / run / test the core Agent	agent.build, agent.run, agent.image
cluster_agent.py	Cluster Agent flavor	cluster-agent.build, cluster-agent.image
dogstatsd.py	DogStatsD	dogstatsd.build, dogstatsd.test
trace_agent.py	Trace Agent	trace-agent.build, trace-agent.run
system_probe.py	System Probe	system-probe.build, system-probe.kitchen-prepare
security_agent.py	Security Agent	security-agent.build, security-agent.bench
process_agent.py	Process Agent	process-agent.build
installer.py	Datadog installer	installer.build
otel_agent.py	OTel Agent flavor	otel-agent.build
serverless_init.py	Serverless flavor	serverless-init.build, serverless-init.image
linter.py	All linting	linter.go, linter.python, linter.shell, linter.copyrights, linter.all
gotest.py, test_core.py	Test orchestration	test, gointegrationtest.run
release.py, release_metrics/	Release management	release.add-release-note, release.tag-version
pipeline.py, gitlab_helpers.py	GitLab CI helpers	Pipeline simulation, job inspection
ebpf.py, system_probe.py	eBPF tooling	ebpf.build, ebpf.gen-usm-events-types
kmt.py, kernel_matrix_testing/	Kernel Matrix Testing	kmt.gen-config, kmt.test
omnibus.py, package.py, msi.py	Packaging	omnibus.build, package.build, msi.build
protobuf.py	Protobuf codegen	protobuf.generate
mockery.yaml-driven generation	Test mocks	(see per-module tasks)
new_e2e_tests.py, e2e_framework/	E2E test runner	new-e2e-tests.run
fakeintake.py	Fakeintake utilities	fakeintake.build, fakeintake.up-cli
rtloader.py	CPython runtime loader	rtloader.make, rtloader.test
winbuild.py, winbuildscripts/	Windows-specific builds	(mostly internal)
vscode.py, vim.py, emacs.py	Editor integration	vscode.setup, emacs.setup
update_go.py	Coordinated Go version bump	update-go.update-go
tools/, commands/, libs/	Helpers shared between tasks	(used internally)

There are about 80 task modules in total. dda inv --list is the canonical index.

Bazel

Bazel coexists with Invoke. bazel/ and BUILD.bazel files define the new build system.

Common targets:

# Run all Bazel tests
bazel test //pkg/aggregator/... //comp/core/...

# Build all eBPF programs
bazel build //pkg/ebpf:all_ebpf_programs

# Verify generated cgo godefs files
bazel test //pkg/ebpf:verify_generated_files

# Build a distributable package
bazel build //packages/agent/linux:debian

After editing go.mod:

dda inv tidy              # Regenerates BUILD.bazel files in sync

bazel/AGENTS.md documents the project's Bazel conventions and pitfalls. The eBPF macros — ebpf_prog, ebpf_program_suite, cgo_godefs, runtime_compilation_bundle — are documented in bazel/rules/ebpf/.

Pre-commit

.pre-commit-config.yaml wires up the local hooks: gofmt, golangci-lint, copyright checks, YAML lint, shell lint, and several custom checks like:

• License-header presence
• Mockery freshness
• BUILD.bazel sync
• Release-note format

Install once:

pre-commit install

After that, hooks run on every git commit.

Code generation

The repo has a lot of generated code. Where to look:

Generator	What it produces	How to run
mockery	_mock.go files	Per-package tasks; tasks/mockery_test.py validates
stringer	*_string.go files	go generate ./... (under the right tags)
protoc	*.pb.go files	dda inv protobuf.generate
easyjson	*_easyjson.go files	go generate in the directory
cgo godefs	pkg/ebpf/.../*_linux.go, *_windows.go	bazel run //pkg/ebpf:types_godefs
Component generation	Component scaffolds	.claude/skills/create-component/ skill, dda inv components.create
Schema dump	agent createschema	./bin/agent/agent createschema

Linters

dda inv linter.go              # golangci-lint with the project config
dda invest linter.python       # ruff, etc.
dda inv linter.shell           # shellcheck
dda inv linter.yaml            # yamllint
dda inv linter.copyrights      # copyright-overrides.yml-aware copyright validation
dda inv linter.all             # everything

Configuration files:

• .golangci.yml — Go.
• .copyright-overrides.yml — exemptions to the copyright header rule.
• pyproject.toml — Python linter and tooling.
• .markdown-link-check, .linkcheckerrc — markdown link checking.
• .golangci.yml includes a custom set of project-specific linters under tools/ and pkg/static_quality_gates/.

Editor and IDE setup

Editor integration tasks generate config for VSCode, IntelliJ/GoLand, Emacs, and Vim:

dda inv vscode.setup
dda inv emacs.setup
dda inv vim.setup

There's also .vscode/ and .devcontainer/ for ready-to-go environments.

CI helpers

Tool	Purpose
tasks/pipeline.py	Simulate or inspect a GitLab pipeline locally
tasks/notify.py	Slack notification logic for pipeline failures
tasks/quality_gates.py, static_quality_gates/	Static analysis quality gates that block PRs
.gitlab/	The GitLab CI templates
.github/workflows/	The GitHub Actions workflows (auxiliary CI)

Skills (.claude/skills/)

Datadog ships a set of "skills" — markdown-defined procedures for AI agents — that document common tasks step by step:

• create-component, create-core-check, create-config-field, create-runtime-setting, create-status-provider, create-subcommand, create-go-module, create-invoke-task
• go-to-bazel, omnibus-to-bazel — migration playbooks
• write-e2e, run-e2e — E2E testing
• quality-gate-size-analysis, review-pr-comments, create-pr, create-release-note, auto-jira, run-jira

These are useful for humans too — they capture the canonical sequence for each task. They live in .claude/skills/ and are mirrored as Cursor rules in .cursor/rules/.

Static analysis

• Datadog static analysis is configured in static-analysis.datadog.yml.
• TEST_RESULTS.md captures expected test runner behavior for some integration paths.
• tools/ holds custom one-off binaries (build helpers, schema validators, etc.).

Reno-style release notes

Release notes use the reno format. Each note is a YAML file under releasenotes/notes/:

---
features:
  - |
    Brief description of the new feature, in present tense.
fixes:
  - |
    Brief description of the bug fix.

Generate one:

dda inv release.add-release-note "summary"

Notes are aggregated into CHANGELOG.rst at release time. The Cluster Agent has its own releasenotes-dca/notes/ and CHANGELOG-DCA.rst.