Document support for running jobs in CI Visibility (#37643)

* Document support for running jobs in CI Visibility

* Mark running jobs as supported for custom CI providers

* Clarify running job identifier and add heading spacing

* Remove intermediate update events from running jobs

* Remove intermediate update events from running jobs

Author: rodrigo-roca

content/en/continuous_integration/pipelines/_index.md

@@ -57,7 +57,7 @@ Select your CI provider to set up CI Visibility in Datadog:
 | {{< ci-details title="Logs collection" >}}Retrieval of pipeline or job logs from the CI provider. Logs are displayed on the <strong>Logs</strong> tab in the Pipeline Execution view.{{< /ci-details >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} |  | {{< X >}} | {{< X >}} | {{< X >}} |  |  |
 | {{< ci-details title="Infrastructure correlation" >}}Correlation of host-level information for the Datadog Agent, CI pipelines, or job runners to CI pipeline execution data.{{< /ci-details >}} |  |  | {{< X >}} |  |  | {{< X >}} | {{< X >}} | {{< X >}} |  |  |
 | {{< ci-details title="Running pipelines" >}}Identification of pipelines executions that are running with associated tracing.{{< /ci-details >}} | {{< X >}} | | | | | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} |
-| {{< ci-details title="Running jobs" >}}Identification of job executions that are running with associated tracing.{{< /ci-details >}} |  |  |  |  |  | {{< X >}} | {{< X >}} |  |  |  |
+| {{< ci-details title="Running jobs" >}}Identification of job executions that are running with associated tracing.{{< /ci-details >}} |  |  |  |  |  | {{< X >}} | {{< X >}} |  |  | {{< X >}} |
 | {{< ci-details title="Partial retries" >}}Identification of partial retries (for example, when only a subset of jobs were retried).{{< /ci-details >}} | {{< X >}} | {{< X >}} | {{< X >}} |  | {{< X >}} | {{< X >}} | {{< X >}} |  | {{< X >}} |  {{< X >}} |
 | {{< ci-details title="Step granularity" >}}Step level spans are available for more granular visibility.{{< /ci-details >}} |  |  |  |  | {{< X >}} | {{< X >}} |  | {{< X >}} <br /> (_Presented as job spans_) |  |  {{< X >}} |
 | {{< ci-details title="Manual steps" >}}Identification of when there is a job with a manual approval phase in the overall pipeline.{{< /ci-details >}} | {{< X >}} | {{< X >}} | {{< X >}} |  | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} |  |  {{< X >}} |

content/en/continuous_integration/pipelines/custom.md

@@ -94,6 +94,7 @@ To send pipeline events programmatically to Datadog, ensure that your [`DD_API_K
 3. After sending your pipeline event to Datadog, you can integrate additional event types such as `stage`, `job`, and `step`. For more information, see the [Send Pipeline Event endpoint][1].
 
 ## Running pipelines
+
 Pipeline events sent with the `status` set to `running` have the same `unique_id` as the final pipeline event. Running pipelines can be updated by adding more information while they are still running. A running pipeline consists of the following events:
 
 1. The initial running pipeline event with the `status` set to `running`.
@@ -102,6 +103,15 @@ Pipeline events sent with the `status` set to `running` have the same `unique_id
 
 **Note**: The most recent value may not always be the one displayed in the UI when a field is updated. For example, if the tag `my_tag` is set to `value1` in the first running pipeline, and then is updated to `value2`, you may see `value1` instead of `value2` in the UI. It is recommended to only update running pipelines by adding more fields instead modifying existing ones.
 
+## Running jobs
+
+Job events can also be sent while a job is still running by setting the `status` to `running`. As with running pipelines, all events for the same job share the same `id` and `pipeline_unique_id`. A running job consists of the following events:
+
+1. The initial running job event with the `status` set to `running`.
+2. The final job event with a terminal status (such as `success` or `error`) and the same `id` and `pipeline_unique_id`.
+
+A running job event does not require an `end` time. The `end` time is set when the final job event is sent.
+
 ## Visualize pipeline data in Datadog
 
 The [**CI Pipeline List**][3] and [**Executions**][4] pages populate with data after the pipelines are accepted for processing.