Continuous integration¶
Tests¶
All Agent Integrations use Azure Pipelines to execute tests.
Execution¶
Every runner will execute test stages in the following order:
- Unit & integration
- E2E
- Benchmarks
Platforms¶
We make extensive use of Microsoft-hosted agents.
- Windows-only integrations run on Windows Server 2019 with Visual Studio 2019
- All other integrations run on Ubuntu 18.04 LTS
Some things are tested on multiple platforms, like the base package and the Disk check.
Pipelines¶
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.
Master¶
Every commit to the master branch triggers one or more jobs for every integration.
Scripts¶
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 will be executed in lexicographical order.
Validations¶
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.
Tip
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.
Tip
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.
Codeowners¶
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
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 construc 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.
Tip
If you see a failure regarding use of the screen endpoint, consider using our dashboard utility command to generate your dashboard payload.
Dependencies¶
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.
Metadata¶
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 README.md 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".
Tip
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.
Imports¶
ddev validate imports
from datadog_checks.base.foo import bar
Tip
See the New Integration Instructions for more examples of how to use the base package.
Labeler¶
We use a GitHub Action to automatically add labels to pull requests.
Tip
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.
Fork¶
We forked the official action to support the following:
- actions/labeler!43
- actions/labeler!44
- a special
all:prefix modifier indicating the pattern must match every file
Docs¶
Stale bot¶
We use a GitHub App that is configured to address abandoned issues and pull requests.