This page is about running Continuous Testing tests in your continuous integration (CI) and continuous delivery (CD) pipelines. If you want to bring your CI/CD metrics and data into Datadog dashboards, see the CI Visibility section.
In addition to running tests at predefined intervals, you can reuse your Datadog Synthetic tests and run them on-demand using the @datadog/datadog-ci package or the API. Run Datadog Continuous Testing tests in your continuous integration (CI) pipelines to block branches from being deployed and breaking your application in production.
Use Continuous Testing and CI/CD to also run tests as part of your continuous delivery (CD) process and evaluate the state of your applications and services in production immediately after a deployment finishes, or a new release is freshly cut. You can detect potential regressions that may impact your users and automatically trigger a rollback when a critical test fails.
This functionality reduces time spent fixing issues in production by proactively catching bugs and regressions earlier in the process, allowing your engineering teams to focus on non-urgent work instead.
With Continuous Testing and CI/CD, you can run Continuous Testing tests in any CI platform provider of choice. See the documentation for information about the following integrations, or read more about the Datadog CI NPM package:
You can trigger tests by searching with tags. For example, use "ci": "datadog-ci synthetics run-tests --config fileconfig.json -s 'tag:staging'". This command works as an argument. Do not use this in your configuration files.
The Synthetics API endpoints allow you to launch tests at any stage in your staging and deployment lifecycle. For example, after a canary deployment with an automated rollback.
Use the API endpoints to quickly verify that a new deployment does not introduce any regression. See the Trigger tests from CI/CD pipelines and Get details of batch endpoints to use them within your CI through cURL or a supported client.
The TEST_TO_TRIGGER objects compose of the required public_id for the test you want to trigger and the optional configuration overrides. For descriptions of each field, see Configure tests.
A test’s public identifier is either the identifier of the test found in the URL of a test’s details page (for example: the identifier for https://app.datadoghq.com/synthetics/details/abc-def-ghi is abc-def-ghi) or the full URL of a test’s details page (for example: https://app.datadoghq.com/synthetics/details/abc-def-ghi).
The get batch details endpoint retrieves results for the group of tests triggered in your CI/CD pipeline, otherwise known as a batch. You must provide the batch_id for the relevant CI execution.
