From 288936a73e066dad000fb39077240f1f57897284 Mon Sep 17 00:00:00 2001 From: Rodrigo Roca Date: Mon, 22 Jun 2026 09:29:15 +0200 Subject: [PATCH 1/5] Document support for running jobs in CI Visibility --- content/en/continuous_integration/pipelines/custom.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/content/en/continuous_integration/pipelines/custom.md b/content/en/continuous_integration/pipelines/custom.md index 4fc84c95119..300e7b19ea9 100644 --- a/content/en/continuous_integration/pipelines/custom.md +++ b/content/en/continuous_integration/pipelines/custom.md @@ -102,6 +102,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`. A running job consists of the following events: + +1. The initial running job event with the `status` set to `running`. +2. Optionally, `N` running job events that update the job with more information, with the same `id` and the `status` set to `running`. +3. The final job event with a terminal status (such as `success` or `error`) and the same `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. From 61ffc72895568372c09f2352bc43501e6450d37b Mon Sep 17 00:00:00 2001 From: Rodrigo Roca Date: Tue, 23 Jun 2026 12:42:24 +0200 Subject: [PATCH 2/5] Mark running jobs as supported for custom CI providers --- content/en/continuous_integration/pipelines/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/continuous_integration/pipelines/_index.md b/content/en/continuous_integration/pipelines/_index.md index 12aaf4a7aed..c4e6774afe7 100644 --- a/content/en/continuous_integration/pipelines/_index.md +++ b/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 Logs 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 >}}
(_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 >}} | From 800808a3425c7f17e2dd55fd2d5c4e316ed9f62b Mon Sep 17 00:00:00 2001 From: Rodrigo Roca Date: Tue, 23 Jun 2026 14:28:35 +0200 Subject: [PATCH 3/5] Clarify running job identifier and add heading spacing --- content/en/continuous_integration/pipelines/custom.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/en/continuous_integration/pipelines/custom.md b/content/en/continuous_integration/pipelines/custom.md index 300e7b19ea9..5ab8f0c2db3 100644 --- a/content/en/continuous_integration/pipelines/custom.md +++ b/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`. @@ -103,7 +104,8 @@ 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`. A running job consists of the following events: + +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. Optionally, `N` running job events that update the job with more information, with the same `id` and the `status` set to `running`. From 6c03c8631a86d2c065a9f057fe11ad5d280f8cd2 Mon Sep 17 00:00:00 2001 From: Rodrigo Roca Date: Tue, 23 Jun 2026 15:04:32 +0200 Subject: [PATCH 4/5] Remove intermediate update events from running jobs --- content/en/continuous_integration/pipelines/custom.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/en/continuous_integration/pipelines/custom.md b/content/en/continuous_integration/pipelines/custom.md index 5ab8f0c2db3..8dce6231389 100644 --- a/content/en/continuous_integration/pipelines/custom.md +++ b/content/en/continuous_integration/pipelines/custom.md @@ -108,8 +108,7 @@ Pipeline events sent with the `status` set to `running` have the same `unique_id 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. Optionally, `N` running job events that update the job with more information, with the same `id` and the `status` set to `running`. -3. The final job event with a terminal status (such as `success` or `error`) and the same `id`. +2. The final job event with a terminal status (such as `success` or `error`) and the same `id`. A running job event does not require an `end` time. The `end` time is set when the final job event is sent. From b1402a5d8517a03035fcbfa161e43340011b70f7 Mon Sep 17 00:00:00 2001 From: Rodrigo Roca Date: Tue, 23 Jun 2026 15:05:16 +0200 Subject: [PATCH 5/5] Remove intermediate update events from running jobs --- content/en/continuous_integration/pipelines/custom.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/continuous_integration/pipelines/custom.md b/content/en/continuous_integration/pipelines/custom.md index 8dce6231389..3bc4e0a1c3d 100644 --- a/content/en/continuous_integration/pipelines/custom.md +++ b/content/en/continuous_integration/pipelines/custom.md @@ -108,7 +108,7 @@ Pipeline events sent with the `status` set to `running` have the same `unique_id 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`. +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.