[pull] master from DataDog:master

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

hugo/content/en/code_coverage/configuration.md

@@ -45,6 +45,7 @@ gates:
       threshold: 95
 comments:
   enabled: true
+  file_breakdown: true
 ```
 
 ## Services configuration
@@ -295,16 +296,40 @@ 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
 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 >}}

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

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 </br> Unencrypted </br> Encrypted - Platform Managed Key (PMK) and Customer Managed Key (CMK)                             | Encrypted - Platform Managed Key (PMK): Azure Disk Storage Server-Side Encryption, Encryption at host </br> **Note**: Encrypted - Customer Managed Key (CMK) is **not** supported | Encrypted - Platform Managed Key (PMK): Persistent Disk Encryption, Confidential VM </br> **Note**: Encrypted - Customer Managed Encryption Key (CMEK) and Customer-Supplied Encryption Keys (CSEK) are **not** supported |
 | Container runtime                               | Docker, containerd </br> **Note**: CRI-O is **not** supported                                                                 | Docker, containerd </br> **Note**: CRI-O is **not** supported                                                                                                                     | Docker, containerd </br> **Note**: CRI-O is **not** supported                                                                                                                                                             |
 | Serverless                                      | AWS Lambda <br> AWS Fargate for ECS                                                                                           | Azure Functions ([Preview][20]), Azure Container Apps, Azure Container Instances<br />**Note**: Requires the latest agentless scanner. See [Update Agentless Scanning][17].                                     | Cloud Run ([Preview][21])                                                                                                                                           |
-| Kubernetes                                      | EKS on EC2 nodes </br> EKS on Fargate </br> **Note**: EKS on Fargate requires the [Datadog Cluster Agent][18] to be installed | AKS on virtual machines and Virtual Machine Scale Sets (VMSS) </br> **Note**: AKS on ACI is **not** supported                                                                     | GKE Standard only </br> **Note**: GKE Autopilot and image streaming are **not** supported                                                                                                                                 |
+| Kubernetes                                      | EKS on EC2 nodes </br> EKS on Fargate </br> **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) </br> **Note**: AKS on ACI requires the [Datadog Cluster Agent][18] to be installed | GKE Standard and GKE Autopilot </br> **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<br />**Note:** At-rest registry scanning is not supported. To request it, contact [Datadog Support][16]   | Google Artifact Registry: Scans images from running workloads only<br />**Note**: Google Artifact Registry at-rest scanning support is in [Preview][19]                                                                                                                                        |
 | Host Images                                     | AMI                                                                                                                           | Not supported                                                                                                                                                                     | Not supported                                                                                                                                                                                                             |

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:
 

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. |
 
 <div class="alert alert-info">State actions have minimum version requirements for each programming language's instrumentation library. See <a href="#compatibility">Compatibility</a> for details.</div>
@@ -88,6 +88,7 @@ Configure automated Flaky Test Policies to govern how flaky tests are handled in
          <td>{{< ui >}}Fixed{{< /ui >}}</td>
          <td>
            <p>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.</p>
+           <p>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 >}}.</p>
            <p>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.</p>
            <p>Use the {{< ui >}}Broken test{{< /ui >}} facet in the Flaky Tests Management explorer to identify these tests. Filter on <code>broken_test:true</code> to show tests with a 100% failure rate over the last 7 days.</p>
          </td>
@@ -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.