diff --git a/hugo/content/en/actions/connections/http.md b/hugo/content/en/actions/connections/http.md index a3496e81df5..56654839e0c 100644 --- a/hugo/content/en/actions/connections/http.md +++ b/hugo/content/en/actions/connections/http.md @@ -64,8 +64,9 @@ The Token Auth connection uses a bearer token to authenticate the HTTP request. 1. Enter a {{< ui >}}Connection Name{{< /ui >}}. 1. Enter the {{< ui >}}Base URL{{< /ui >}} for authentication. 1. From the {{< ui >}}Authentication Type{{< /ui >}} dropdown, select {{< ui >}}Token Auth{{< /ui >}}. -1. Enter a {{< ui >}}Token Name{{< /ui >}} and {{< ui >}}Token Value{{< /ui >}}. You can enter multiple tokens. To reference your token in a header, parameter, or the request body, use the syntax `{{ secretTokenName }}`. -1. Optionally, add additional {{< ui >}}Request Headers{{< /ui >}}, {{< ui >}}URL parameters{{< /ui >}} and a {{< ui >}}Body{{< /ui >}} to your request. +1. Enter a {{< ui >}}Token Name{{< /ui >}} and {{< ui >}}Token Value{{< /ui >}}. You can enter multiple tokens. +1. Configure how HTTP requests that use the connection include the token. The connection does not add the token to requests automatically. In {{< ui >}}Request Headers{{< /ui >}}, {{< ui >}}URL parameters{{< /ui >}}, or the {{< ui >}}Body{{< /ui >}}, reference the token with the syntax `{{ secretTokenName }}`, replacing `secretTokenName` with the {{< ui >}}Token Name{{< /ui >}} from the previous step. For example, if the token name is `apiToken`, add an `Authorization` header with the value `Bearer {{ apiToken }}`. +1. Optionally, add other {{< ui >}}Request Headers{{< /ui >}}, {{< ui >}}URL parameters{{< /ui >}}, or a {{< ui >}}Body{{< /ui >}} to your request. 1. Click {{< ui >}}Create{{< /ui >}}. ### Create an HTTP basic authentication connection diff --git a/hugo/content/en/api/v2/feature-flags/examples.json b/hugo/content/en/api/v2/feature-flags/examples.json index c73080ead5e..9098214b397 100644 --- a/hugo/content/en/api/v2/feature-flags/examples.json +++ b/hugo/content/en/api/v2/feature-flags/examples.json @@ -185,13 +185,6 @@ "description": "This is an example feature flag for demonstration", "key": "feature-flag-abc123", "name": "Feature Flag ABC123", - "rule_targets": [ - { - "configuration": {}, - "type": "SLACK_CHANNEL", - "version": 1 - } - ], "value_type": "BOOLEAN", "variants": [ { @@ -212,31 +205,6 @@ "json_schema": "{\"type\": \"object\", \"properties\": {\"enabled\": {\"type\": \"boolean\"}}}", "key": "feature-flag-abc123", "name": "Feature Flag ABC123", - "notification_rule_query": "notification_type:rollout_started OR notification_type:targeting_rule_updated", - "rule_targets": [ - { - "configuration": { - "channel": "#feature-flags", - "channel_id": "C0123456789", - "channel_name": "Feature Flags", - "connector_name": "datadog-connector", - "recipient": { - "email": "user@example.com" - }, - "service_name": "feature-flags-oncall", - "team_id": "19:abcdef0123456789@thread.tacv2", - "team_name": "Engineering", - "tenant_id": "72f988bf-86f1-41af-91ab-2d7cd011db47", - "tenant_name": "Datadog", - "username": "jane.doe", - "webhook_name": "feature-flags-webhook", - "workspace": "datadoghq", - "workspace_id": "T0123456789" - }, - "type": "SLACK_CHANNEL", - "version": 1 - } - ], "value_type": "BOOLEAN", "variants": [ { @@ -249,7 +217,7 @@ "type": "feature-flags" } }, - "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

Data for creating a new feature flag.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

Attributes for creating a new feature flag.

\n
\n
\n
\n
\n
\n

default_variant_key

\n
\n

string

\n

The key of the default variant.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

The description of the feature flag.

\n
\n \n
\n
\n
\n
\n
\n

json_schema

\n
\n

string

\n

JSON schema for validation when value_type is JSON.

\n
\n \n
\n
\n
\n
\n
\n

key [required]

\n
\n

string

\n

The unique key of the feature flag.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The name of the feature flag.

\n
\n \n
\n
\n
\n
\n
\n

notification_rule_query

\n
\n

string

\n

Query used to determine which change events on this feature flag trigger notifications\nto rule_targets. Uses Datadog log search syntax (AND, OR, NOT, parentheses) to\nmatch against the notification_type facet.

Supported notification_type values for a feature flag are: flag_enabled_disabled,\nflag_archived, flag_approval_required, rollout_started, rollout_scheduled,\nrollout_step_started, rollout_paused_guardrail, rollout_paused_user,\nrollout_aborted_guardrail, rollout_aborted_user, targeting_rule_created,\ntargeting_rule_updated, targeting_rule_updated_via_filter, and\ntargeting_rule_deleted.

\n
\n \n
\n
\n
\n
\n
\n

rule_targets

\n
\n

[object]

\n

Targets to notify about changes to this feature flag that match notification_rule_query.

\n
\n
\n
\n
\n
\n

configuration [required]

\n
\n

object

\n

Configuration for a notification target. Which fields apply depends on the target's type.

\n
\n
\n
\n
\n
\n

channel

\n
\n

string

\n

Slack channel name, for a SLACK_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n

channel_id

\n
\n

string

\n

Slack channel ID for a SLACK_CHANNEL target, or Microsoft Teams channel ID\nfor an MS_TEAMS_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n

channel_name

\n
\n

string

\n

Microsoft Teams channel name, for an MS_TEAMS_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n

connector_name

\n
\n

string

\n

Microsoft Teams connector name, for an MS_TEAMS_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n

recipient

\n
\n

object

\n

Recipient for an EMAIL target.

\n
\n
\n
\n
\n
\n

email

\n
\n

string

\n

Email address to notify.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

service_name

\n
\n

string

\n

PagerDuty service name, for a PAGERDUTY_SERVICE target.

\n
\n \n
\n
\n
\n
\n
\n

team_id

\n
\n

string

\n

Microsoft Teams team ID, for an MS_TEAMS_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n

team_name

\n
\n

string

\n

Microsoft Teams team name, for an MS_TEAMS_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n

tenant_id

\n
\n

string

\n

Microsoft Teams tenant ID, for an MS_TEAMS_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n

tenant_name

\n
\n

string

\n

Microsoft Teams tenant name, for an MS_TEAMS_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n

username

\n
\n

string

\n

Slack username, for a SLACK_USER target.

\n
\n \n
\n
\n
\n
\n
\n

webhook_name

\n
\n

string

\n

Name of the configured webhook, for a WEBHOOK target.

\n
\n \n
\n
\n
\n
\n
\n

workspace

\n
\n

string

\n

Slack workspace name, for a SLACK_CHANNEL or SLACK_USER target.

\n
\n \n
\n
\n
\n
\n
\n

workspace_id

\n
\n

string

\n

Slack workspace ID, for a SLACK_CHANNEL target.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

The type of notification target. \nAllowed enum values: EMAIL,SLACK_CHANNEL,SLACK_USER,WEBHOOK,PAGERDUTY_SERVICE,MS_TEAMS_CHANNEL

\n
\n \n
\n
\n
\n
\n
\n

version [required]

\n
\n

int64

\n

Schema version of configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

value_type [required]

\n
\n

enum

\n

The type of values for the feature flag variants. \nAllowed enum values: BOOLEAN,INTEGER,NUMERIC,STRING,JSON

\n
\n \n
\n
\n
\n
\n
\n

variants [required]

\n
\n

[object]

\n

The variants of the feature flag.

\n
\n
\n
\n
\n
\n

key [required]

\n
\n

string

\n

The unique key of the variant.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The name of the variant.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The value of the variant as a string.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

The resource type. \nAllowed enum values: feature-flags

\n
\n \n
\n
\n
\n
" + "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

Data for creating a new feature flag.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

Attributes for creating a new feature flag.

\n
\n
\n
\n
\n
\n

default_variant_key

\n
\n

string

\n

The key of the default variant.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

The description of the feature flag.

\n
\n \n
\n
\n
\n
\n
\n

json_schema

\n
\n

string

\n

JSON schema for validation when value_type is JSON.

\n
\n \n
\n
\n
\n
\n
\n

key [required]

\n
\n

string

\n

The unique key of the feature flag.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The name of the feature flag.

\n
\n \n
\n
\n
\n
\n
\n

value_type [required]

\n
\n

enum

\n

The type of values for the feature flag variants. \nAllowed enum values: BOOLEAN,INTEGER,NUMERIC,STRING,JSON

\n
\n \n
\n
\n
\n
\n
\n

variants [required]

\n
\n

[object]

\n

The variants of the feature flag.

\n
\n
\n
\n
\n
\n

key [required]

\n
\n

string

\n

The unique key of the variant.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The name of the variant.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The value of the variant as a string.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

The resource type. \nAllowed enum values: feature-flags

\n
\n \n
\n
\n
\n
" } }, "ListFeatureFlagsEnvironments": { diff --git a/hugo/content/en/code_coverage/configuration.md b/hugo/content/en/code_coverage/configuration.md index 8d6227b6f78..98716d7a062 100644 --- a/hugo/content/en/code_coverage/configuration.md +++ b/hugo/content/en/code_coverage/configuration.md @@ -45,6 +45,7 @@ gates: threshold: 95 comments: enabled: true + file_breakdown: true ``` ## Services configuration @@ -295,9 +296,20 @@ gates: ## PR Comments -By default, Datadog posts a code coverage summary comment on every pull request. You can suppress it on a per-repository basis with the `comments.enabled` field. +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. -PR Gate checks are not affected by this setting. +The `comments` block accepts the following fields: + +| Field | Type | Default | Description | +|---|---|---|---| +| `enabled` | Boolean | `true` | Whether Datadog posts a code coverage comment on pull requests. | +| `file_breakdown` | Boolean | `false` | Whether the comment includes a per-file table of total and patch coverage. | + +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: {{< code-block lang="yaml" filename="code-coverage.datadog.yml" >}} schema-version: v1 @@ -305,6 +317,19 @@ comments: enabled: false {{< /code-block >}} +### 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: + +{{< code-block lang="yaml" filename="code-coverage.datadog.yml" >}} +schema-version: v1 +comments: + enabled: true + file_breakdown: true +{{< /code-block >}} + +The breakdown has no effect when `comments.enabled` is `false`. + ## Carryforward {{< callout url="#" btn_hidden="true" header="Join the Preview!">}}Carryforward is in Preview and is subject to change.{{< /callout >}} diff --git a/hugo/content/en/code_coverage/setup.md b/hugo/content/en/code_coverage/setup.md index 9da330e9deb..232bbc7a254 100644 --- a/hugo/content/en/code_coverage/setup.md +++ b/hugo/content/en/code_coverage/setup.md @@ -446,7 +446,7 @@ test: The command recursively searches the specified directories for supported coverage report files, so specifying the current directory (`.`) is usually sufficient. See the [`datadog-ci` documentation][14] for more details on the `datadog-ci coverage upload` command. -Shortly after the code coverage report upload is finished, Datadog adds a PR comment with code coverage percentage values. +Shortly after the code coverage report upload is finished, Datadog adds a PR comment with code coverage percentage values. To add a per-file breakdown of total and patch coverage to the comment, see [PR Comments][21]. You can also view your coverage data aggregated by pull request in the [Code Coverage page][15] in Datadog, with the ability to examine individual files and lines of code. {{< img src="/code_coverage/pr_details.png" text="Code Coverage PR details page in Datadog" style="width:100%" >}} @@ -555,3 +555,4 @@ For a description of how reports are merged and how each line status is counted, [18]: /code_coverage/setup/#integrate-with-source-code-provider [19]: https://app.datadoghq.com/organization-settings/data-access-controls [20]: /code_coverage/coverage_calculation +[21]: /code_coverage/configuration#pr-comments diff --git a/hugo/content/en/security/cloud_security_management/setup/agentless_scanning/compatibility.md b/hugo/content/en/security/cloud_security_management/setup/agentless_scanning/compatibility.md index af3f00452a9..82c9dabed88 100644 --- a/hugo/content/en/security/cloud_security_management/setup/agentless_scanning/compatibility.md +++ b/hugo/content/en/security/cloud_security_management/setup/agentless_scanning/compatibility.md @@ -18,7 +18,7 @@ The following table provides a summary of Agentless Scanning technologies in rel | Encryption | AWS
Unencrypted
Encrypted - Platform Managed Key (PMK) and Customer Managed Key (CMK) | Encrypted - Platform Managed Key (PMK): Azure Disk Storage Server-Side Encryption, Encryption at host
**Note**: Encrypted - Customer Managed Key (CMK) is **not** supported | Encrypted - Platform Managed Key (PMK): Persistent Disk Encryption, Confidential VM
**Note**: Encrypted - Customer Managed Encryption Key (CMEK) and Customer-Supplied Encryption Keys (CSEK) are **not** supported | | Container runtime | Docker, containerd
**Note**: CRI-O is **not** supported | Docker, containerd
**Note**: CRI-O is **not** supported | Docker, containerd
**Note**: CRI-O is **not** supported | | Serverless | AWS Lambda
AWS Fargate for ECS | Azure Functions ([Preview][20]), Azure Container Apps, Azure Container Instances
**Note**: Requires the latest agentless scanner. See [Update Agentless Scanning][17]. | Cloud Run ([Preview][21]) | -| Kubernetes | EKS on EC2 nodes
EKS on Fargate
**Note**: EKS on Fargate requires the [Datadog Cluster Agent][18] to be installed | AKS on virtual machines and Virtual Machine Scale Sets (VMSS)
**Note**: AKS on ACI is **not** supported | GKE Standard only
**Note**: GKE Autopilot and image streaming are **not** supported | +| Kubernetes | EKS on EC2 nodes
EKS on Fargate
**Note**: EKS on Fargate requires the [Datadog Cluster Agent][18] to be installed | AKS on VMs, Virtual Machine Scale Sets (VMSS), and Azure Container Instances (ACI)
**Note**: AKS on ACI requires the [Datadog Cluster Agent][18] to be installed | GKE Standard and GKE Autopilot
**Note**: GKE Autopilot requires the [Datadog Cluster Agent][18] to be installed | | Application languages (in hosts and containers) | Java, .Net, Python, Node.js, Go, Ruby, Rust, PHP, Swift, Dart, Elixir, Conan, Conda | Java, .Net, Python, Node.js, Go, Ruby, Rust, PHP, Swift, Dart, Elixir, Conan, Conda | Java, .Net, Python, Node.js, Go, Ruby, Rust, PHP, Swift, Dart, Elixir, Conan, Conda | | Container Registries | Amazon ECR (public and private): Scans running container images and the last 1,000 pushed images at rest | ACR: Scans running container images only
**Note:** At-rest registry scanning is not supported. To request it, contact [Datadog Support][16] | Google Artifact Registry: Scans images from running workloads only
**Note**: Google Artifact Registry at-rest scanning support is in [Preview][19] | | Host Images | AMI | Not supported | Not supported | diff --git a/hugo/content/en/tests/correlate_logs_and_tests/_index.md b/hugo/content/en/tests/correlate_logs_and_tests/_index.md index 163cea091b7..3d1dcfc11e8 100644 --- a/hugo/content/en/tests/correlate_logs_and_tests/_index.md +++ b/hugo/content/en/tests/correlate_logs_and_tests/_index.md @@ -36,11 +36,12 @@ Use the following environment variables to enable and configure Agentless log su | `DD_AGENTLESS_LOG_SUBMISSION_QUEUE_SIZE` (optional) | Sets the maximum size of pending logs queue | `1024` | | `DD_AGENTLESS_LOG_SUBMISSION_URL` (optional) | Sets custom URL for submitting logs | - | -### Javascript/Typescript +### JavaScript/TypeScript -Agentless log submission is supported for the following languages and frameworks: +Agentless log submission is supported for the following tracer versions and logging libraries: -- `dd-trace-js >= 5.24.0` and `dd-trace-js >= 4.48.0` and `winston`. +- `dd-trace-js v4.48.0 or later` on the v4 release line, or `dd-trace-js v5.24.0 or later` on the v5 release line, with `winston`. +- `dd-trace-js v5.124.0 or later` on the v5 release line, or `dd-trace-js v6.13.0 or later` on the v6 release line, with `pino` or `bunyan`. Use the following environment variables to enable and configure Agentless log submission: diff --git a/hugo/content/en/tests/flaky_management/_index.md b/hugo/content/en/tests/flaky_management/_index.md index 82a8d831986..fbff81fd947 100644 --- a/hugo/content/en/tests/flaky_management/_index.md +++ b/hugo/content/en/tests/flaky_management/_index.md @@ -34,7 +34,7 @@ Use the state drop-down to change how a flaky test is handled in your CI pipelin | ----------- | ----------- | | {{< ui >}}Active{{< /ui >}} | The test is known to be flaky and is running in CI. | | {{< ui >}}Quarantined{{< /ui >}} | Keep the test running in the background, but failures don't affect CI status or break pipelines. This is useful for isolating flaky tests without blocking merges. Datadog tags test run events with `@test.test_management.is_quarantined:true` when quarantined. | -| {{< ui >}}Disabled{{< /ui >}} | Skip the test entirely in CI. Use this when a test is no longer relevant or needs to be temporarily removed from the pipeline. Datadog tags test run events with `@test.test_management.is_disabled:true` when disabled. | +| {{< ui >}}Disabled{{< /ui >}} | Skip the test entirely in CI. Use this when a test is no longer relevant or needs to be temporarily removed from the pipeline. Datadog tags test run events with `@test.test_management.is_disabled:true` when disabled. Disabled tests are excluded from the automatic move to {{< ui >}}Fixed{{< /ui >}}. | | {{< ui >}}Fixed{{< /ui >}} | The test has passed consistently and is no longer flaky. If supported, use the [remediation flow](#confirm-fixes-for-flaky-tests) to confirm the fix and automatically apply this state after it is merged into the default branch. |
State actions have minimum version requirements for each programming language's instrumentation library. See Compatibility for details.
@@ -88,6 +88,7 @@ Configure automated Flaky Test Policies to govern how flaky tests are handled in {{< ui >}}Fixed{{< /ui >}}

If a flaky test no longer flakes for 30 days, it is automatically moved to the Fixed state. This automation is default behavior and can't be customized.

+

Tests in the {{< ui >}}Disabled{{< /ui >}} state are excluded from this automation and are never automatically moved to {{< ui >}}Fixed{{< /ui >}}. Because disabled tests are skipped in CI, Datadog has no signal about whether they are still flaky. To make a disabled test eligible again, change its state to {{< ui >}}Active{{< /ui >}} or {{< ui >}}Quarantined{{< /ui >}}.

Before Datadog automatically moves a flaky test to {{< ui >}}Fixed{{< /ui >}}, it checks whether the test may be broken rather than fixed. A broken test is a flaky test whose recent executions all failed, resulting in a 100% failure rate over the last 7 days. Datadog does not automatically mark these tests as fixed, which helps prevent quarantined tests that still fail from breaking CI again.

Use the {{< ui >}}Broken test{{< /ui >}} facet in the Flaky Tests Management explorer to identify these tests. Filter on broken_test:true to show tests with a 100% failure rate over the last 7 days.

@@ -243,6 +244,15 @@ To use Flaky Tests Management features, you must use Datadog's native instrument ## Troubleshooting +### Disabled flaky tests are not automatically moved to Fixed + +Datadog does not automatically move {{< ui >}}Disabled{{< /ui >}} tests to the {{< ui >}}Fixed{{< /ui >}} state, even after they stop flaking for 30 days. A disabled test is skipped in CI, so Datadog receives no test run data for it and cannot verify whether it is still flaky. + +To fix a disabled test, do one of the following: + +- Trigger the [attempt-to-fix remediation flow](#confirm-fixes-for-flaky-tests). It retries the test even while it is disabled, and moves it to {{< ui >}}Fixed{{< /ui >}} once the fix is confirmed and merged. +- Manually change the test's state to {{< ui >}}Active{{< /ui >}} or {{< ui >}}Quarantined{{< /ui >}} using the [state drop-down](#change-a-flaky-tests-state). Datadog then automatically moves the test to {{< ui >}}Fixed{{< /ui >}} the next time the automation runs, unless the test flakes again. + ### Slack notifications are not delivered If Slack notifications are not being delivered, check that your notification rule uses the `@slack-ACCOUNT-CHANNEL` format. diff --git a/hugo/content/en/tests/setup/javascript.md b/hugo/content/en/tests/setup/javascript.md index 3924c41fc4a..92e088b654f 100644 --- a/hugo/content/en/tests/setup/javascript.md +++ b/hugo/content/en/tests/setup/javascript.md @@ -34,7 +34,8 @@ further_reading: | Cucumber | >= 7.0.0 | | Cypress | >= 12.0.0 | | Playwright | >= 1.38.0 | -| Vitest | >= 1.6.0 | [`test.concurrent`](https://vitest.dev/api/#test-concurrent) is supported from `dd-trace>=6.1.0`. | +| Vitest | >= 1.6.0 | [`test.concurrent`](https://vitest.dev/api/#test-concurrent) is supported from `dd-trace>=6.1.0`. [Browser mode](https://vitest.dev/guide/browser/) is supported from `dd-trace>=6.8.0`. | +| WebdriverIO | >= 9.0.0 | Supported with the Mocha and Jasmine framework adapters from `dd-trace>=6.10.0`. | `dd-trace` v6 requires Node.js 22 or later. @@ -48,7 +49,8 @@ further_reading: | Cucumber | >= 7.0.0 | | Cypress | >= 6.7.0 | | Playwright | >= 1.18.0 | -| Vitest | >= 1.6.0 | Supported from `dd-trace>=5.18.0`. [`test.concurrent`](https://vitest.dev/api/#test-concurrent) is supported from `dd-trace>=5.112.0`. | +| Vitest | >= 1.6.0 | Supported from `dd-trace>=5.18.0`. [`test.concurrent`](https://vitest.dev/api/#test-concurrent) is supported from `dd-trace>=5.112.0`. [Browser mode](https://vitest.dev/guide/browser/) is supported from `dd-trace>=5.119.0`. | +| WebdriverIO | >= 9.0.0 | Supported with the Mocha and Jasmine framework adapters from `dd-trace>=5.121.0`. | {{% /tab %}} {{< /tabs >}} @@ -449,6 +451,7 @@ To enable screenshot uploads, set the `DD_TEST_FAILURE_SCREENSHOTS_ENABLED` envi Use a Node.js version supported by your `dd-trace` major version for Vitest instrumentation: + - `dd-trace` v5 requires Node.js 18.19+ or Node.js 20.6+. - `dd-trace` v6 requires Node.js 22 or later. @@ -506,6 +509,70 @@ For more information about custom measures, see the [Add Custom Measures Guide][ [2]: /tests/guides/add_custom_measures/?tab=javascripttypescript {{% /tab %}} +{{% tab "WebdriverIO" %}} +Use a Node.js version supported by your `dd-trace` major version for WebdriverIO instrumentation: + +- `dd-trace` v5 requires Node.js 18.19+ or Node.js 20.6+. +- `dd-trace` v6 requires Node.js 22 or later. + +Set the `NODE_OPTIONS` environment variable to `--import dd-trace/register.js -r dd-trace/ci/init`. Run your tests as you normally would, optionally specifying a name for your test session with `DD_TEST_SESSION_NAME`: + +```bash +NODE_OPTIONS="--import dd-trace/register.js -r dd-trace/ci/init" DD_TEST_SESSION_NAME=e2e-tests yarn test:e2e +``` + +**Note**: If you set a value for `NODE_OPTIONS`, make sure it does not overwrite `--import dd-trace/register.js -r dd-trace/ci/init`. This can be done using the `${NODE_OPTIONS:-}` clause: + +{{< code-block lang="json" filename="package.json" >}} +{ + "scripts": { + "test:e2e": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" wdio run ./wdio.conf.js" + } +} +{{< /code-block >}} + +### Adding custom tags or measures to tests + +You can add custom tags to your tests by using the current active span: + +```javascript +import tracer from 'dd-trace' + +describe('home page', () => { + it('displays the heading', async () => { + const testSpan = tracer.scope().active() + testSpan.setTag('team_owner', 'my_team') + + await browser.url('/') + await expect($('h1')).toBeDisplayed() + }) +}) +``` + +To create filters or `group by` fields for these tags, you must first create facets. For more information about adding tags, see the [Adding Tags][1] section of the Node.js custom instrumentation documentation. + +You can also add custom measures to your tests by using the current active span: + +```javascript +import tracer from 'dd-trace' + +describe('home page', () => { + it('displays the heading', async () => { + const testSpan = tracer.scope().active() + testSpan.setTag('memory_allocations', 16) + + await browser.url('/') + await expect($('h1')).toBeDisplayed() + }) +}) +``` + +For more information about custom measures, see the [Add Custom Measures Guide][2]. + +[1]: /tracing/trace_collection/custom_instrumentation/nodejs?tab=locally#adding-tags +[2]: /tests/guides/add_custom_measures/?tab=javascripttypescript +{{% /tab %}} + {{< /tabs >}} ### How to fix "Cannot find module 'dd-trace/ci/init'" errors @@ -626,7 +693,7 @@ For more information about `service` and `env` reserved tags, see [Unified Servi Note: The manual testing API is available starting in dd-trace versions 5.23.0 and 4.47.0. -If you use Jest, Mocha, Cypress, Playwright, Cucumber, or Vitest, **do not use the manual testing API**, as Test Optimization automatically instruments them and sends the test results to Datadog. The manual testing API is **incompatible** with already supported testing frameworks. +If you use Jest, Mocha, Cypress, Playwright, Cucumber, Vitest, or WebdriverIO, **do not use the manual testing API**. Test Optimization automatically instruments these frameworks and sends the test results to Datadog. The manual testing API is **incompatible** with supported testing frameworks. Use the manual testing API only if you use an unsupported testing framework or have a different testing mechanism. @@ -763,9 +830,6 @@ Jest's [--forceExit][15] option may cause data loss. Datadog tries to send data ### Mocha's `--exit` Mocha's [--exit][16] option may cause data loss. Datadog tries to send data immediately after your tests finish, but shutting down the process abruptly can cause some requests to fail. Use `--exit` with caution. -### Vitest's browser mode -Vitest's [browser mode][17] is not supported. - ### Vitest's test duration overhead By default, Vitest's [`isolate`][21] option is `true`, so each test file runs in its own fork or thread. Vitest is ESM-first and relies on [import-in-the-middle][20] for instrumentation, which incurs a setup cost every time a suite starts. With isolation, that setup cost is repeated for every file. The effect is largest when you have many small, fast suites, because setup time can dominate wall-clock time. @@ -856,7 +920,6 @@ The test session name should be unique within a repository to help you distingui [13]: https://docs.cypress.io/app/core-concepts/test-isolation [15]: https://jestjs.io/docs/cli#--forceexit [16]: https://mochajs.org/running/cli/#--exit -[17]: https://vitest.dev/guide/browser/ [18]: https://jestjs.io/docs/api#testeachtablename-fn-timeout [19]: https://www.npmjs.com/package/mocha-each [20]: https://github.com/nodejs/import-in-the-middle diff --git a/hugo/data/api/v2/CodeExamples.json b/hugo/data/api/v2/CodeExamples.json index 312916faeec..b48c81e3496 100644 --- a/hugo/data/api/v2/CodeExamples.json +++ b/hugo/data/api/v2/CodeExamples.json @@ -801,11 +801,6 @@ "group": "feature_flags", "suffix": "", "description": "Create a feature flag returns \"Created\" response" - }, - { - "group": "feature_flags", - "suffix": "_2426084719", - "description": "Create a feature flag with notification rule targets returns \"Created\" response" } ], "CreateAllocationsForFeatureFlagInEnvironment": [ diff --git a/hugo/data/api/v2/full_spec.yaml b/hugo/data/api/v2/full_spec.yaml index 8a9e72a83b0..8b21ae04abb 100644 --- a/hugo/data/api/v2/full_spec.yaml +++ b/hugo/data/api/v2/full_spec.yaml @@ -1649,7 +1649,7 @@ components: type: string ResourceID: description: |- - Identifier, formatted as `type:id`. Supported types: `dashboard`, `integration-service`, `integration-webhook`, `notebook`, `powerpack`, `reference-table`, `security-rule`, `slo`, `synthetics-global-variable`, `synthetics-test`, `synthetics-private-location`, `monitor`, `workflow`, `app-builder-app`, `connection`, `connection-group`, `rum-application`, `cross-org-connection`, `spreadsheet`, `on-call-schedule`, `on-call-escalation-policy`, `on-call-team-routing-rules`, `logs-pipeline`, `case-management-project`, `monitor-notification-rule`, `status-page`, `feature-flag`. + Identifier, formatted as `type:id`. Supported types: `dashboard`, `integration-service`, `integration-webhook`, `notebook`, `powerpack`, `reference-table`, `security-rule`, `slo`, `synthetics-global-variable`, `synthetics-test`, `synthetics-private-location`, `monitor`, `workflow`, `app-builder-app`, `connection`, `connection-group`, `rum-application`, `cross-org-connection`, `spreadsheet`, `on-call-schedule`, `on-call-escalation-policy`, `on-call-team-routing-rules`, `logs-pipeline`, `case-management-project`, `monitor-notification-rule`, `status-page`, `feature-flag`, `network-path-config`. example: "dashboard:abc-def-ghi" in: path name: resource_id @@ -24865,26 +24865,6 @@ components: description: The name of the feature flag. example: "Feature Flag ABC123" type: string - notification_rule_query: - description: |- - Query used to determine which change events on this feature flag trigger notifications - to `rule_targets`. Uses Datadog log search syntax (`AND`, `OR`, `NOT`, parentheses) to - match against the `notification_type` facet. - - Supported `notification_type` values for a feature flag are: `flag_enabled_disabled`, - `flag_archived`, `flag_approval_required`, `rollout_started`, `rollout_scheduled`, - `rollout_step_started`, `rollout_paused_guardrail`, `rollout_paused_user`, - `rollout_aborted_guardrail`, `rollout_aborted_user`, `targeting_rule_created`, - `targeting_rule_updated`, `targeting_rule_updated_via_filter`, and - `targeting_rule_deleted`. - example: "notification_type:rollout_started OR notification_type:targeting_rule_updated" - nullable: true - type: string - rule_targets: - description: Targets to notify about changes to this feature flag that match `notification_rule_query`. - items: - $ref: "#/components/schemas/NotificationRuleTarget" - type: array value_type: $ref: "#/components/schemas/ValueType" variants: @@ -71983,109 +71963,6 @@ components: type: string x-enum-varnames: - MANUAL - NotificationRuleTarget: - description: A notification target that receives change alerts for a feature flag. - properties: - configuration: - $ref: "#/components/schemas/NotificationRuleTargetConfiguration" - type: - $ref: "#/components/schemas/NotificationRuleTargetType" - version: - description: Schema version of `configuration`. - example: 1 - format: int64 - type: integer - required: - - type - - version - - configuration - type: object - NotificationRuleTargetConfiguration: - description: "Configuration for a notification target. Which fields apply depends on the target's `type`." - properties: - channel: - description: Slack channel name, for a `SLACK_CHANNEL` target. - example: "#feature-flags" - type: string - channel_id: - description: |- - Slack channel ID for a `SLACK_CHANNEL` target, or Microsoft Teams channel ID - for an `MS_TEAMS_CHANNEL` target. - example: "C0123456789" - type: string - channel_name: - description: Microsoft Teams channel name, for an `MS_TEAMS_CHANNEL` target. - example: "Feature Flags" - type: string - connector_name: - description: Microsoft Teams connector name, for an `MS_TEAMS_CHANNEL` target. - example: "datadog-connector" - type: string - recipient: - $ref: "#/components/schemas/NotificationRuleTargetConfigurationRecipient" - service_name: - description: PagerDuty service name, for a `PAGERDUTY_SERVICE` target. - example: "feature-flags-oncall" - type: string - team_id: - description: Microsoft Teams team ID, for an `MS_TEAMS_CHANNEL` target. - example: "19:abcdef0123456789@thread.tacv2" - type: string - team_name: - description: Microsoft Teams team name, for an `MS_TEAMS_CHANNEL` target. - example: "Engineering" - type: string - tenant_id: - description: Microsoft Teams tenant ID, for an `MS_TEAMS_CHANNEL` target. - example: "72f988bf-86f1-41af-91ab-2d7cd011db47" - type: string - tenant_name: - description: Microsoft Teams tenant name, for an `MS_TEAMS_CHANNEL` target. - example: "Datadog" - type: string - username: - description: Slack username, for a `SLACK_USER` target. - example: "jane.doe" - type: string - webhook_name: - description: Name of the configured webhook, for a `WEBHOOK` target. - example: "feature-flags-webhook" - type: string - workspace: - description: Slack workspace name, for a `SLACK_CHANNEL` or `SLACK_USER` target. - example: "datadoghq" - type: string - workspace_id: - description: Slack workspace ID, for a `SLACK_CHANNEL` target. - example: "T0123456789" - type: string - type: object - NotificationRuleTargetConfigurationRecipient: - description: Recipient for an `EMAIL` target. - properties: - email: - description: Email address to notify. - example: "user@example.com" - type: string - type: object - NotificationRuleTargetType: - description: The type of notification target. - enum: - - "EMAIL" - - "SLACK_CHANNEL" - - "SLACK_USER" - - "WEBHOOK" - - "PAGERDUTY_SERVICE" - - "MS_TEAMS_CHANNEL" - example: "SLACK_CHANNEL" - type: string - x-enum-varnames: - - EMAIL - - SLACK_CHANNEL - - SLACK_USER - - WEBHOOK - - PAGERDUTY_SERVICE - - MS_TEAMS_CHANNEL NotificationRulesListResponse: description: The list of notification rules. properties: @@ -191705,6 +191582,7 @@ paths: - Monitor Notification Rules: `monitor-notification-rule` - Status Pages: `status-page` - Feature Flags: `feature-flag` + - Network Path Configs: `network-path-config` #### Supported relations for resources Resource Type | Supported Relations @@ -191736,6 +191614,7 @@ paths: Monitor Notification Rules | `viewer`, `editor` Status Pages | `viewer`, `responder`, `manager` Feature Flags | `viewer`, `contributor`, `editor` + Network Path Configs | `viewer`, `editor` operationId: UpdateRestrictionPolicy parameters: - $ref: "#/components/parameters/ResourceID" diff --git a/hugo/data/api/v2/translate_actions.json b/hugo/data/api/v2/translate_actions.json index c9dcb4e3907..6cca6bda831 100644 --- a/hugo/data/api/v2/translate_actions.json +++ b/hugo/data/api/v2/translate_actions.json @@ -5032,7 +5032,7 @@ "summary": "Get a restriction policy" }, "UpdateRestrictionPolicy": { - "description": "Updates the restriction policy associated with a resource.\n\n#### Supported resources\nRestriction policies can be applied to the following resources:\n- Dashboards: `dashboard`\n- Integration Services: `integration-service`\n- Integration Webhooks: `integration-webhook`\n- Notebooks: `notebook`\n- Powerpacks: `powerpack`\n- Reference Tables: `reference-table`\n- Security Rules: `security-rule`\n- Service Level Objectives: `slo`\n- Synthetic Global Variables: `synthetics-global-variable`\n- Synthetic Tests: `synthetics-test`\n- Synthetic Private Locations: `synthetics-private-location`\n- Monitors: `monitor`\n- Workflows: `workflow`\n- App Builder Apps: `app-builder-app`\n- Connections: `connection`\n- Connection Groups: `connection-group`\n- RUM Applications: `rum-application`\n- Cross Org Connections: `cross-org-connection`\n- Spreadsheets: `spreadsheet`\n- On-Call Schedules: `on-call-schedule`\n- On-Call Escalation Policies: `on-call-escalation-policy`\n- On-Call Team Routing Rules: `on-call-team-routing-rules`\n- Logs Pipelines: `logs-pipeline`\n- Case Management Projects: `case-management-project`\n- Monitor Notification Rules: `monitor-notification-rule`\n- Status Pages: `status-page`\n- Feature Flags: `feature-flag`\n\n#### Supported relations for resources\nResource Type | Supported Relations\n----------------------------|--------------------------\nDashboards | `viewer`, `editor`\nIntegration Services | `viewer`, `editor`\nIntegration Webhooks | `viewer`, `editor`\nNotebooks | `viewer`, `editor`\nPowerpacks | `viewer`, `editor`\nSecurity Rules | `viewer`, `editor`\nService Level Objectives | `viewer`, `editor`\nSynthetic Global Variables | `viewer`, `editor`\nSynthetic Tests | `viewer`, `editor`\nSynthetic Private Locations | `viewer`, `editor`\nMonitors | `viewer`, `editor`\nReference Tables | `viewer`, `editor`\nWorkflows | `viewer`, `runner`, `editor`\nApp Builder Apps | `viewer`, `editor`\nConnections | `viewer`, `resolver`, `editor`\nConnection Groups | `viewer`, `editor`\nRUM Application | `viewer`, `editor`\nCross Org Connections | `viewer`, `editor`\nSpreadsheets | `viewer`, `editor`\nOn-Call Schedules | `viewer`, `overrider`, `editor`\nOn-Call Escalation Policies | `viewer`, `editor`\nOn-Call Team Routing Rules | `viewer`, `editor`\nLogs Pipelines | `viewer`, `processors_editor`, `editor`\nCase Management Projects | `viewer`, `contributor`, `manager`\nMonitor Notification Rules | `viewer`, `editor`\nStatus Pages | `viewer`, `responder`, `manager`\nFeature Flags | `viewer`, `contributor`, `editor`", + "description": "Updates the restriction policy associated with a resource.\n\n#### Supported resources\nRestriction policies can be applied to the following resources:\n- Dashboards: `dashboard`\n- Integration Services: `integration-service`\n- Integration Webhooks: `integration-webhook`\n- Notebooks: `notebook`\n- Powerpacks: `powerpack`\n- Reference Tables: `reference-table`\n- Security Rules: `security-rule`\n- Service Level Objectives: `slo`\n- Synthetic Global Variables: `synthetics-global-variable`\n- Synthetic Tests: `synthetics-test`\n- Synthetic Private Locations: `synthetics-private-location`\n- Monitors: `monitor`\n- Workflows: `workflow`\n- App Builder Apps: `app-builder-app`\n- Connections: `connection`\n- Connection Groups: `connection-group`\n- RUM Applications: `rum-application`\n- Cross Org Connections: `cross-org-connection`\n- Spreadsheets: `spreadsheet`\n- On-Call Schedules: `on-call-schedule`\n- On-Call Escalation Policies: `on-call-escalation-policy`\n- On-Call Team Routing Rules: `on-call-team-routing-rules`\n- Logs Pipelines: `logs-pipeline`\n- Case Management Projects: `case-management-project`\n- Monitor Notification Rules: `monitor-notification-rule`\n- Status Pages: `status-page`\n- Feature Flags: `feature-flag`\n- Network Path Configs: `network-path-config`\n\n#### Supported relations for resources\nResource Type | Supported Relations\n----------------------------|--------------------------\nDashboards | `viewer`, `editor`\nIntegration Services | `viewer`, `editor`\nIntegration Webhooks | `viewer`, `editor`\nNotebooks | `viewer`, `editor`\nPowerpacks | `viewer`, `editor`\nSecurity Rules | `viewer`, `editor`\nService Level Objectives | `viewer`, `editor`\nSynthetic Global Variables | `viewer`, `editor`\nSynthetic Tests | `viewer`, `editor`\nSynthetic Private Locations | `viewer`, `editor`\nMonitors | `viewer`, `editor`\nReference Tables | `viewer`, `editor`\nWorkflows | `viewer`, `runner`, `editor`\nApp Builder Apps | `viewer`, `editor`\nConnections | `viewer`, `resolver`, `editor`\nConnection Groups | `viewer`, `editor`\nRUM Application | `viewer`, `editor`\nCross Org Connections | `viewer`, `editor`\nSpreadsheets | `viewer`, `editor`\nOn-Call Schedules | `viewer`, `overrider`, `editor`\nOn-Call Escalation Policies | `viewer`, `editor`\nOn-Call Team Routing Rules | `viewer`, `editor`\nLogs Pipelines | `viewer`, `processors_editor`, `editor`\nCase Management Projects | `viewer`, `contributor`, `manager`\nMonitor Notification Rules | `viewer`, `editor`\nStatus Pages | `viewer`, `responder`, `manager`\nFeature Flags | `viewer`, `contributor`, `editor`\nNetwork Path Configs | `viewer`, `editor`", "summary": "Update a restriction policy", "request_description": "Restriction policy payload", "request_schema_description": "Update request for a restriction policy."