Overview

You can configure Code Coverage behavior by creating a configuration file named code-coverage.datadog.yml or code-coverage.datadog.yaml in the root of your repository.

Example configuration file:

schema-version: v1
services:
  - id: frontend
    paths:
      - frontend/
      - shared/ui/**
  - id: backend-api
    paths:
      - backend/api/**
      - backend/.*\.go
ignore:
  - "test/**/*"
  - "**/*.pb.go"
gates:
  - type: total_coverage_percentage
    config:
      threshold: 85
  - type: patch_coverage_percentage
    config:
      threshold: 95
comments:
  enabled: true
  file_breakdown: true

Services configuration

You can define services in your configuration file to split coverage data by service in monorepos. This is useful when multiple projects or teams share a single repository and you want to view coverage metrics for each service independently.

schema-version: v1
services:
  - id: frontend
    paths:
      - frontend/**
      - shared/ui/**
  - id: backend-api
    paths:
      - backend/api/**

• schema-version (required): Must be v1
• services: List of service definitions
  • id (required): Unique identifier for the service
  • paths (required): List of path patterns that belong to this service (see Pattern syntax)

For complete details on monorepo support, including Catalog integration and code owner-based splitting, see Monorepo Support.

Examples

schema-version: v1
services:
  - id: web-app
    paths:
      - packages/web/**
      - packages/shared/ui/**
  - id: mobile-app
    paths:
      - packages/mobile/**
      - packages/shared/core/**
  - id: admin-dashboard
    paths:
      - packages/admin/**

schema-version: v1
services:
  - id: backend-service
    paths:
      - services/backend/**
      - services/backend/.*\.go
  - id: frontend-web
    paths:
      - services/frontend/**
      - services/frontend/.*\.(ts|tsx)
  - id: data-processing
    paths:
      - services/data/**
      - scripts/.*\.py

Ignoring paths

You can exclude specific files or directories from code coverage reporting using the ignore field. This is useful for excluding test files, generated code, vendor dependencies, and other files that should not be included in coverage metrics. Path patterns support glob, regex, and prefix matching (see Pattern syntax).

ignore:
  - "test/**/*"           # Exclude all files in test directory
  - "*.pb.go"             # Exclude all protobuf generated files
  - "vendor/"             # Exclude vendor directory

Exceptions

Add ! before a pattern to create an exception to your ignore rules. This lets you include specific files or folders that would otherwise be excluded.

ignore:
  - "generated/"          # Ignore all generated code
  - "!generated/core/"    # Except core generated files

Important: Negative patterns take precedence over positive patterns. If any negative pattern matches a file path, that path is not ignored.

Examples

ignore:
  - "**/*_test.go"        # Exclude Go test files
  - "**/*.pb.go"          # Exclude protobuf files
  - "vendor/"             # Exclude vendor directory
  - "mocks/"              # Exclude mock files

ignore:
  - "generated/"          # Ignore all generated code
  - "!generated/core/"    # Except core generated files
  - "test/"               # Ignore test directory
  - "!test/integration/"  # Except integration tests

ignore:
  - "^vendor/.*"          # Regex: exclude vendor (anchored)
  - "**/*.min.js"         # Glob: exclude minified JS files
  - "dist/"               # Prefix: exclude dist directory
  - ".*\\.pb\\.go$"       # Regex: exclude protobuf files

PR Gates

You can define PR Gates in the configuration file to enforce code coverage thresholds on pull requests. If gates are also configured in the Datadog UI, Datadog evaluates both the configuration file rules and the UI rules when a PR is opened or updated.

gates:
  - type: total_coverage_percentage
    config:
      threshold: 85

  - type: patch_coverage_percentage
    config:
      threshold: 95

Each gate has the following fields:

• type (required): The type of coverage gate. Supported values:
  • total_coverage_percentage: The minimum overall coverage percentage for the repository (or for the scoped services or code owners).
  • patch_coverage_percentage: The minimum coverage percentage on code changed in the pull request.
• config (required): Gate configuration options. Supported values:
  • threshold (required): The minimum coverage percentage (0-100).
  • services: (optional) A list of service name patterns to scope the gate to. Use * as a wildcard. Prefix a value with ! to exclude matching services. When set, coverage is evaluated separately for each matching service.
  • codeowners: (optional) A list of code owner patterns to scope the gate to. Use * as a wildcard. Prefix a value with ! to exclude matching code owners. When set, coverage is evaluated separately for each matching code owner.
  • flags: (optional) A list of flag name patterns to scope the gate to. Use * as a wildcard. Prefix a value with ! to exclude matching flags. When set, coverage is evaluated separately for each matching flag.

Examples

schema-version: v1
gates:
  - type: total_coverage_percentage
    config:
      threshold: 80

  - type: patch_coverage_percentage
    config:
      threshold: 90

schema-version: v1
services:
  - id: backend-api
    paths:
      - backend/api/**
  - id: frontend-web
    paths:
      - frontend/**
gates:
  - type: patch_coverage_percentage
    config:
      threshold: 90
      services:
        - "*"

  - type: total_coverage_percentage
    config:
      threshold: 85
      services:
        - "backend-api"

schema-version: v1
gates:
  - type: patch_coverage_percentage
    config:
      threshold: 95
      codeowners:
        - "@DataDog/backend-team"
        - "@DataDog/api-*"

  - type: total_coverage_percentage
    config:
      threshold: 80
      codeowners:
        - "@DataDog/frontend-team"

schema-version: v1
gates:
  - type: total_coverage_percentage
    config:
      threshold: 80
      flags:
        - "unit-tests"

  - type: patch_coverage_percentage
    config:
      threshold: 90
      flags:
        - "integration-tests"

schema-version: v1
gates:
  - type: total_coverage_percentage
    config:
      threshold: 80
      services:
        - "*"
        - "!experimental-*"

  - type: patch_coverage_percentage
    config:
      threshold: 90
      flags:
        - "*"
        - "!nightly-*"

PR Comments

By default, Datadog posts a code coverage summary comment on every pull request. The summary reports the total and patch coverage for the pull request and links to the Code Coverage page in Datadog.

The comments block accepts the following fields:

PR Gate checks are not affected by these settings.

Disabling PR comments

You can suppress the comment on a per-repository basis with the comments.enabled field:

schema-version: v1
comments:
  enabled: false

Per-file breakdown

Set comments.file_breakdown to true to add a table to the comment listing the files changed in the pull request, along with their total coverage and patch coverage:

schema-version: v1
comments:
  enabled: true
  file_breakdown: true

The breakdown has no effect when comments.enabled is false.

Carryforward

You can enable carryforward in the configuration file to reuse coverage data from ancestor commits when not every CI job runs for a commit. Carryforward operates on flags, so every report involved must be tagged with --flags.

To enable carryforward for every flag in the repository:

schema-version: v1
carryforward: true

To enable carryforward for specific flags only:

schema-version: v1
flags:
  unit-tests:
    carryforward: true
  integration-tests:
    carryforward: true

The top-level carryforward field accepts the following values:

• true: Carryforward is enabled for every flag, unless a flag overrides it with carryforward: false in the flags map.
• false (default): Carryforward is disabled, unless a flag opts in with carryforward: true in the flags map.

The flags map accepts a per-flag configuration block. The supported fields are:

• carryforward: A Boolean that enables or disables carryforward for the named flag. Overrides the top-level carryforward value.

For complete details, see Code Coverage Carryforward.

Pattern syntax

Configuration options that accept file paths support three types of patterns:

• regex
• glob
• path_prefix

The pattern type is automatically detected based on the syntax you use.

Regex patterns

Patterns containing regex-specific characters (+, {, }, |, (, ), ^, $, \) are treated as regular expressions:

• ".*\\.pb\\.go$" - Matches files ending with .pb.go
• "^generated/.*" - Matches files in the generated directory
• ".*_test\\.go$" - Matches test files

Note: Regex patterns are automatically anchored with ^...$ for whole-path matching. Use forward slashes (/) as path separators in regex patterns.

Glob patterns

Patterns containing glob-specific characters (*, ?, [, ]) are treated as glob patterns:

• "**/*.java" - Matches all Java files
• "src/test/**/*" - Matches all files under src/test
• "*.pb.go" - Matches protobuf files in any directory

Note: Use ** to match directories recursively. The pattern folder/* matches only direct children, while folder/**/* matches all descendants.

Prefix patterns

Simple path prefixes without special characters are treated as prefix matches:

• "vendor/" - Matches all files under vendor directory
• "third_party/" - Matches third-party code
• "generated/" - Matches generated code

Further reading

Additional helpful documentation, links, and articles:

Code CoverageDOCUMENTATION Set up Code CoverageDOCUMENTATION Organize coverage data with flagsDOCUMENTATION Keep total coverage accurate with carryforwardDOCUMENTATION