[CIVIS-3137] Replace wall time documentation with new metric "total s…

…essions duration" (#20486)

* replace wall time documentation with new metric 'total sessions duration'

* remove mentions to wall time

* update images

* Update content/en/continuous_integration/guides/flaky_test_management.md

Co-authored-by: Ursula Chen <[email protected]>

* Update content/en/continuous_integration/search/_index.md

Co-authored-by: Ursula Chen <[email protected]>

* Update content/en/continuous_integration/search/_index.md

Co-authored-by: Ursula Chen <[email protected]>

* Update content/en/continuous_integration/search/_index.md

Co-authored-by: Ursula Chen <[email protected]>

* Update content/en/continuous_integration/troubleshooting.md

Co-authored-by: Ursula Chen <[email protected]>

* Update content/en/continuous_integration/troubleshooting.md

Co-authored-by: Ursula Chen <[email protected]>

* Update content/en/continuous_integration/troubleshooting.md

Co-authored-by: Ursula Chen <[email protected]>

* Update content/en/continuous_integration/troubleshooting.md

Co-authored-by: Ursula Chen <[email protected]>

---------

Co-authored-by: Ursula Chen <[email protected]>

content/en/continuous_integration/guides/flaky_test_management.md

@@ -22,7 +22,7 @@ A [flaky test][1] is a test that exhibit both a passing and failing status acros
 
 Flaky tests introduce risk and unpredictability into your CI system and end product. When people have to remember which tests are flaky, they lose trust in their test results, and a tremendous amount of time and resources are wasted on pipeline retries.
 
-For each branch, the list shows the number of new flaky tests introduced by the commit, the number of flaky commits, a comparison of the current wall time with the average default branch wall time, and the branch's latest commit details. 
+For each branch, the list shows the number of new flaky tests introduced by the commit, the number of flaky commits, total test time, and the branch's latest commit details. 
 
 Use the following information to help prioritize flaky tests:
 

content/en/continuous_integration/search/_index.md

@@ -102,7 +102,7 @@ You can access low-level and immediate insights:
 
 - See what tests are failing and why.
 - See your last commit's test results.
-- View the wall time of your tests in your feature branch and compare it to the default branch, to identify if you're about to introduce a performance regression.
+- View the total duration of your tests in your feature branch.
 - Find out if your commit introduces a new [flaky test][105] that wasn't flaky before, indicating that your code change is what's making it flaky. This gives you the opportunity to fix the problem before proceeding rather than contributing to the number of flaky tests in your CI.
 
 You can also access high-level accumulation and trends:
@@ -123,18 +123,14 @@ In this page, you can filter the list by name, test service, or commit SHA, or t
 
 #### Test results
 
-For each branch, you can see the test service, the number of failed, passed, and skipped tests, test regressions, wall time, the percentage of change compared to the default branch, when the commit was last updated, and the avatar of the author of the commit.
+For each branch, you can see the test service, the number of failed, passed, and skipped tests, test regressions, total test time, when the commit was last updated, and the avatar of the author of the commit.
+
+Hovering over the commit author's avatar shows detailed information about the latest commit.
 
 Click on a branch to explore the test details page, which includes information about the branch's latest commits, flaky tests, test performance, common error types, and all test runs.
 
 {{< img src="continuous_integration/test_details.png" alt="Test Details page for a single branch" style="width:100%;">}}
 
-#### Test suite performance
-
-There is also information about the [wall time][104] of the most recent test suite run, and a comparison to the average wall time of the default branch. The comparison of your branch's wall time to the default branch's wall time can help you determine if your commit is introducing performance [regressions][106] to your test suite.
-
-Hovering over the commit author avatar shows detailed information about the latest commit.
-
 #### Test regressions
 
 [Test regressions][106] are evaluated per commit in an effort to tie performance regressions to specific code changes.
@@ -153,7 +149,7 @@ Click the CI provider link to examine the Resource, Service, or Analytics page f
 
 The [Default Branches][107] view of the Tests page shows aggregated health metrics for the _default_ branch of each test service. This view is useful for teams to understand the overall health of the service over time.
 
-The Default Branches view shows similar information to the Branches view, but applied to the default branch. It compares the current wall time with the average default branch wall time to give you an indication of how your test suite performance is trending over time.
+The Default Branches view shows similar information to the Branches view, but applied to the default branch.
 
 [101]: https://app.datadoghq.com/ci/test-services
 [102]: https://app.datadoghq.com/ci/test-services?view=branches

content/en/continuous_integration/troubleshooting.md

@@ -93,28 +93,20 @@ If you can see test results data in the **Test Runs** tab, but not the **Tests**
 
 4. If no CI provider environment variables are found, tests results are sent with no Git metadata.
 
-### The tests wall time is empty
+### The total test time is empty
+If you cannot see the total test time, it is likely that test suite level visibility is not enabled. To confirm, check if your language supports test suite level visibility in [Supported features][15]. If test suite level visibility is supported, update your tracer to the latest version.
 
-If you cannot see the tests wall time it is likely that the CI provider metadata is missing. To confirm this is the case, open a test execution in the [**Test Runs**][4] section, and check if the `ci.pipeline.id`, `ci.pipeline.name`, `ci.pipeline.number`, or `ci.job.url` tags are missing. If these tags are not populated, then nothing shows in the wall time column.
+If after updating the tracer version you still don't see the total time, contact [Datadog support][2] for help.
 
-1. Tracers use the environment variables set by the CI provider to collect this information. See [Running tests inside a container][7] for a list of environment variables that the tracer attempts to read for each supported CI provider. Make sure that the environment variables have the expected values set.
-2. Check that you are running your tests in a supported CI provider. For a list of supported CI providers, see [Running tests inside a container][7]. Only these CI providers can extract the information to enrich the test metadata with CI information.
-3. If you still don't see the wall time, contact [Datadog support][2] for help.
+### The total test time is different than expected
 
-### The tests wall time is not what is expected
-
-#### How wall time is calculated
-The wall time is defined as the time difference between the start time of the first test and the end time of the last test for the given pipeline.
+#### How total time is calculated
+The total time is defined as the sum of the maximum test session durations.
 
 This is done using the following algorithm:
 
-1. Compute a hash based on CI information to group the tests.
-    1. If the tests include `ci.job.url`, use this tag to calculate the hash.
-    2. If the tests don't include `ci.job.url`, use `ci.pipeline.id` + `ci.pipeline.name` + `ci.pipeline.number` to calculate the hash.
-2. The calculated wall time is associated to a given hash. **Note**: If there are multiple jobs that execute tests, the wall time is calculated for each job, and the maximum from all calculated wall times is shown.
-
-#### Possible issues with wall time calculation
-If you're using a library for testing time-dependent code, like [timecop][8] for Ruby or [FreezeGun][9] for Python, it is possible that test timestamps are wrong, and therefore calculated wall times. If this is the case, make sure that modifications to time are rolled back before finishing your tests.
+1. Compute the maximum duration of a test session grouped by the test session fingerprint.
+2. Sum the maximum test session durations.
 
 ### The test status numbers are not what is expected
 
@@ -153,8 +145,6 @@ The default branch is used to power some features of the products, namely:
 
 - Default branches list on the Tests page: This list only displays default branches. Setting the wrong default branch can result in missing or incorrect data in the default branches list.
 
-- Wall time comparison for non-default branches: On the Tests page, in the Branches view, the **VS Default** column is calculated by comparing wall time for the current branch against wall time for the default branch.
-
 - New flaky tests: Tests that are not currently classified as flaky in the default branch. If the default branch is not properly set, this could lead to a wrong number of detected new flaky tests.
 
 - Pipelines list: The pipelines list only displays default branches. Setting the wrong default branch can result in missing or incorrect data in the pipelines list.
@@ -221,11 +211,10 @@ If you are authoring a commit that includes any of those cases, you can force-di
 [5]: https://app.datadoghq.com/ci/test-services
 [6]: /tracing/troubleshooting/tracer_debug_logs
 [7]: /continuous_integration/tests/containers/
-[8]: https://github.com/travisjeffery/timecop
-[9]: https://github.com/spulec/freezegun
-[10]: /continuous_integration/tests/junit_upload/?tabs=linux#collecting-environment-configuration-metadata
-[11]: https://app.datadoghq.com/ci/settings/repository
-[12]: /continuous_integration/intelligent_test_runner/
-[13]: https://developer.harness.io/kb/continuous-integration/articles/using_git_credentials_from_codebase_connector_in_ci_pipelines_run_step/
-[14]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork#syncing-a-fork-branch-from-the-web-ui
-[15]: /api/latest/ci-visibility-pipelines/#send-pipeline-event
+[8]: /continuous_integration/tests/junit_upload/?tabs=linux#collecting-environment-configuration-metadata
+[9]: https://app.datadoghq.com/ci/settings/repository
+[10]: /continuous_integration/intelligent_test_runner/
+[11]: https://developer.harness.io/kb/continuous-integration/articles/using_git_credentials_from_codebase_connector_in_ci_pipelines_run_step/
+[12]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork#syncing-a-fork-branch-from-the-web-ui
+[13]: /api/latest/ci-visibility-pipelines/#send-pipeline-event
+[14]: /continuous_integration/tests/#supported-features