Skip to content

Continuous integration


All Agent Integrations use Azure Pipelines to execute tests.


Every runner will execute test stages in the following order:

  1. Unit & integration
  2. E2E
  3. Benchmarks


We make extensive use of Microsoft-hosted agents.

Some things are tested on multiple platforms, like the base package and the Disk check.


Pull requests

Every commit to a branch tied to an open pull request triggers a Linux and Windows job. Each runner will test any integration that was changed, with the Windows runner being further restricted to Windows-only integrations.

If the base package is modified, jobs will be triggered for every integration, similar to the pipeline for master.


Every commit to the master branch triggers one or more jobs for every integration.


Some integrations require additional set up such as the installation of system dependencies. As we only want these extra steps to occur when necessary, there is a stage ran for every job that will detect what needs to be done and execute the appropriate scripts. As integrations may need different set up on different platforms, all scripts live under a directory named after the platform. All scripts in the directory are executed in lexicographical order. Files in the scripts directory whose names begin with an underscore are not executed.


In addition to running tests on our CI, there are also some validations that are run to check for correctness of changes to various components of integrations. If any of these validations fail on your branch, then the CI will fail.

In short, each validation is a ddev command, which fails if the component it is validating is not correct.

See the ddev documentation and source code for the full docs for each validation.


A list of the current validations can be found here.

CI configuration

ddev validate ci

This validates that all CI entries for integrations are valid. This includes checking if the integration has the correct codecov config, and has a valid CI entry if it is testable.


Run ddev validate ci --fix to resolve most errors.

Agent requirements

ddev validate agent-reqs

This validates that each integration version is in sync with the requirements-agent-release.txt file. It is uncommon for this to fail because the release process is automated.


ddev validate codeowners

This validates that every integration has a codeowner entry. If you fail this validation, add an entry in the codewners file corresponding to any newly added integration.

Note: This validation command is only run when contributing to integrations-extras

Default configuration files

ddev validate config
This verifies that the config specs for all integrations are valid by enforcing our configuration spec schema. The most common failure at this validation stage is some version of File <INTEGRATION_SPEC> needs to be synced. To resolve this issue, you can run ddev validate config --sync

If you see failures regarding formatting or missing parameters, see our config spec documentation for more details on how to construct configuration specs.

Dashboard definition files

ddev validate dashboards

This validates that dashboards are formatted correctly. This means that they need to be proper JSON and generated from Datadog's /dashboard API.


If you see a failure regarding use of the screen endpoint, consider using our dashboard utility command to generate your dashboard payload.


ddev validate dep

This command:

  • Verifies the uniqueness of dependency versions across all checks.
  • Verifies all the dependencies are pinned.
  • Verifies the embedded Python environment defined in the base check and requirements listed in every integration are compatible.

This validation only applies if your work introduces new external dependencies.

Manifest files

ddev validate manifest

This validates that the manifest files contain required fields, are formatted correctly, and don't contain common errors. See the Datadog docs for more detailed constraints.


ddev validate metadata

This checks that every metadata.csv file is formatted correctly. See the Datadog docs for more detailed constraints.

README files

ddev validate readmes

This ensures that every integration's file is formatted correctly. The main purpose of this validation is to ensure that any image linked in the readme exists and that all images are located in an integration's /image directory.

Saved views data

ddev validate saved-views

This validates that saved views for an integration are formatted correctly and contain required fields, such as "type".


View example saved views for inspiration and guidance.

Service check data

ddev validate service-checks

This checks that every service check file is formatted correctly. See the Datadog docs for more specific constraints.


ddev validate imports
This verifies that all integrations import the base package in the correct way, such as:

from import bar


See the New Integration Instructions for more examples of how to use the base package.


We use a GitHub Action to automatically add labels to pull requests.


If the Labeler CI step fails on your PR, it's probably because your PR is from a fork. Don't worry if this happens- the team can manually add labels for you.

The labeler is configured to add the following:

Label Condition
integration/<NAME> any directory at the root that actually contains an integration
documentation any Markdown, config specs, manifest.json, or anything in /docs/
dev/testing Codecov or Azure Pipelines config
dev/tooling GitLab (see CD), GitHub Actions, or Stale bot config, or the ddev CLI
dependencies any change in shipped dependencies
release any base package, dev package, or integration release
changelog/no-changelog any release, or if all files don't modify code that is shipped

The changelog/<TYPE> label must be applied manually.


We forked the official action to support the following:


Stale bot

We use a GitHub App that is configured to address abandoned issues and pull requests.

Last update: December 10, 2021