Informations de référence sur la table système de travaux

Cet article est une référence relative aux tables système lakeflow qui enregistrent l’activité des travaux dans votre compte. Ces tables incluent des enregistrements de tous les espaces de travail de votre compte déployés dans la même région cloud. Pour afficher les enregistrements d’une autre région, vous devez afficher les tables d’un espace de travail déployé dans cette région.

Requirements

• Pour accéder à ces tables système, les utilisateurs doivent :
  • Être à la fois un administrateur de metastore et un administrateur de compte, ou
  • Disposer des autorisations USE et SELECT sur les schémas système. Consultez Octroyer un accès aux tables système.

Tables de travaux disponibles

Toutes les tables système liées au travail résident dans le schéma system.lakeflow. Actuellement, le schéma héberge quatre tables :

Informations de référence détaillées sur le schéma

Les sections suivantes fournissent des références de schéma pour chacune des tables système liées aux travaux.

Schéma de la table des travaux

La table jobs est une table de dimension à variation lente (SCD2). Lorsqu’une ligne change, une nouvelle ligne est émise, remplaçant logiquement la ligne précédente.

Chemin d’accès de la table : system.lakeflow.jobs

Exemple de requête

-- Get the most recent version of a job
SELECT
  *,
  ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM
  system.lakeflow.jobs QUALIFY rn=1

Schéma de la table des tâches

La table tâches de travail est une table de dimensions à variation lente (SCD2). Lorsqu’une ligne change, une nouvelle ligne est émise, remplaçant logiquement la ligne précédente.

Chemin d’accès de la table : system.lakeflow.job_tasks

Exemple de requête

-- Get the most recent version of a job task
SELECT
  *,
  ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM
  system.lakeflow.job_tasks QUALIFY rn=1

Schéma de la table de chronologie d'exécution de la tâche

La table de chronologie d'exécution de la tâche est immuable et terminée au moment où elle est produite.

Chemin d’accès de la table : system.lakeflow.job_run_timeline

Exemple de requête

-- This query gets the daily job count for a workspace for the last 7 days:
SELECT
  workspace_id,
  COUNT(DISTINCT run_id) as job_count,
  to_date(period_start_time) as date
FROM system.lakeflow.job_run_timeline
WHERE
  period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
GROUP BY ALL

-- This query returns the daily job count for a workspace for the last 7 days, distributed by the outcome of the job run.
SELECT
  workspace_id,
  COUNT(DISTINCT run_id) as job_count,
  result_state,
  to_date(period_start_time) as date
FROM system.lakeflow.job_run_timeline
WHERE
  period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
  AND result_state IS NOT NULL
GROUP BY ALL

-- This query returns the average time of job runs, measured in seconds. The records are organized by job. A top 90 and a 95 percentile column show the average lengths of the job's longest runs.
with job_run_duration as (
    SELECT
        workspace_id,
        job_id,
        run_id,
        CAST(SUM(period_end_time - period_start_time) AS LONG) as duration
    FROM
        system.lakeflow.job_run_timeline
    WHERE
      period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
    GROUP BY ALL
)
SELECT
    t1.workspace_id,
    t1.job_id,
    COUNT(DISTINCT t1.run_id) as runs,
    MEAN(t1.duration) as mean_seconds,
    AVG(t1.duration) as avg_seconds,
    PERCENTILE(t1.duration, 0.9) as p90_seconds,
    PERCENTILE(t1.duration, 0.95) as p95_seconds
FROM
    job_run_duration t1
GROUP BY ALL
ORDER BY mean_seconds DESC
LIMIT 100

-- This query provides a historical runtime for a specific job based on the `run_name` parameter. For the query to work, you must set the `run_name`.
SELECT
  workspace_id,
  run_id,
  SUM(period_end_time - period_start_time) as run_time
FROM system.lakeflow.job_run_timeline
WHERE
  run_type="SUBMIT_RUN"
  AND run_name = :run_name
  AND period_start_time > CURRENT_TIMESTAMP() - INTERVAL 60 DAYS
GROUP BY ALL

-- This query collects a list of retried job runs with the number of retries for each run.
with repaired_runs as (
    SELECT
    workspace_id, job_id, run_id, COUNT(*) - 1 as retries_count
    FROM system.lakeflow.job_run_timeline
    WHERE result_state IS NOT NULL
    GROUP BY ALL
    HAVING retries_count > 0
    )
SELECT
    *
FROM repaired_runs
ORDER BY retries_count DESC
    LIMIT 10;

Schéma de la table de chronologie d'exécution de la tâche de travail

La table de chronologie d'exécution de la tâche de travail est immuable et terminée au moment où elle est produite.

Chemin d’accès de la table : system.lakeflow.job_task_run_timeline

Schéma de la table des pipelines

La table pipelines est une table de dimension à variation lente (SCD2). Lorsqu’une ligne change, une nouvelle ligne est émise, remplaçant logiquement la ligne précédente.

Chemin d’accès de la table : system.lakeflow.pipelines

Exemple de requête

-- Get the most recent version of a pipeline
SELECT
  *,
  ROW_NUMBER() OVER(PARTITION BY workspace_id, pipeline_id ORDER BY change_time DESC) as rn
FROM
  system.lakeflow.pipelines QUALIFY rn=1

-- Enrich billing logs with pipeline metadata
with latest_pipelines AS (
  SELECT
    *,
    ROW_NUMBER() OVER(PARTITION BY workspace_id, pipeline_id ORDER BY change_time DESC) as rn
  FROM
    system.lakeflow.pipelines QUALIFY rn=1
)
SELECT
  usage.*,
  pipelines.*
FROM system.billing.usage
LEFT JOIN latest_pipelines
  ON (usage.workspace_id = pipelines.workspace_id
    AND usage.usage_metadata.dlt_pipeline_id = pipelines.pipeline_id)
WHERE
  usage.usage_metadata.dlt_pipeline_id IS NOT NULL

Schéma de la table des délais de mise à jour du pipeline

La table de mise à jour du calendrier du pipeline est immuable et complète au moment où elle est produite.

Chemin d’accès de la table : system.lakeflow.pipeline_update_timeline

Exemple de requête

-- This query gets the daily pipeline update count for a workspace for the last 7 days:
SELECT
    workspace_id,
    COUNT(DISTINCT update_id) as update_count,
    to_date(period_start_time) as date
FROM system.lakeflow.pipeline_update_timeline
WHERE
    period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
GROUP BY ALL

-- This query returns the daily pipeline update count for a workspace for the last 7 days, distributed by the outcome of the pipeline update.
SELECT
    workspace_id,
    COUNT(DISTINCT update_id) as update_count,
    result_state,
    to_date(period_start_time) as date
FROM system.lakeflow.pipeline_update_timeline
WHERE
    period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
  AND result_state IS NOT NULL
GROUP BY ALL

-- This query returns the average time of pipeline updates, measured in seconds. The records are organized by pipeline. A top 90 and a 95 percentile column show the average lengths of the pipeline's longest updates.
with pipeline_update_duration as (
    SELECT
      workspace_id,
      pipeline_id,
      update_id,
      CAST(SUM(period_end_time - period_start_time) AS LONG) as duration
    FROM
        system.lakeflow.pipeline_update_timeline
    WHERE
        period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
    GROUP BY ALL
)
SELECT
    t1.workspace_id,
    t1.pipeline_id,
    COUNT(DISTINCT t1.update_id) as update_count,
    MEAN(t1.duration) as mean_seconds,
    AVG(t1.duration) as avg_seconds,
    PERCENTILE(t1.duration, 0.9) as p90_seconds,
    PERCENTILE(t1.duration, 0.95) as p95_seconds
FROM
    pipeline_update_duration t1
GROUP BY ALL
ORDER BY mean_seconds DESC
    LIMIT 100

modèles de jointure courants

Les sections suivantes fournissent des exemples de requêtes qui mettent en évidence les modèles de jointure couramment utilisés pour les tables système de travaux.

Joindre les tables des travaux et des chronologies d’exécution des travaux

Enrichir l’exécution d’un travail avec un nom de travail

with jobs as (
    SELECT
        *,
        ROW_NUMBER() OVER (PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
    FROM system.lakeflow.jobs QUALIFY rn=1
)
SELECT
    job_run_timeline.*
    jobs.name
FROM system.lakeflow.job_run_timeline
    LEFT JOIN jobs USING (workspace_id, job_id)

Joindre les tables d'utilisation et des chronologies d’exécution des travaux

Enrichir chaque journal de facturation avec les métadonnées d’exécution du travail

La requête suivante enrichit les journaux de facturation avec les métadonnées d’exécution de travaux classiques et sans serveur :

with aggregated_job_runs AS (
  SELECT
    j.workspace_id,
    COALESCE(t.job_id, j.job_id) as origin_job_id,
    COALESCE(t.job_run_id, j.run_id) AS origin_job_run_id,
    j.job_id as billing_job_id,
    j.run_id as billing_run_id,
    CASE WHEN j.root_task_run_id IS NOT NULL THEN true ELSE false END AS is_workflow_run
  FROM
    system.lakeflow.job_run_timeline j
  LEFT JOIN
    system.lakeflow.job_task_run_timeline t
  ON
    j.workspace_id = t.workspace_id
    AND j.root_task_run_id = t.run_id
  WHERE j.period_start_time >= CURRENT_DATE() - INTERVAL 7 DAYS
  GROUP BY ALL
),
billing_logs_enriched AS (
  SELECT
      t2.origin_job_id,
      t2.origin_job_run_id,
      t1.*
  FROM system.billing.usage t1
      INNER JOIN aggregated_job_runs t2
          ON t1.workspace_id = t2.workspace_id
              AND t1.usage_metadata.job_id = t2.billing_job_id
              AND t1.usage_metadata.job_run_id = t2.billing_run_id
  WHERE
      billing_origin_product="JOBS" AND usage_date >= CURRENT_DATE() - INTERVAL 7 DAYS
)
SELECT
  workspace_id,
  origin_job_id AS job_id,
  origin_job_run_id AS run_id,
  sku_name,
  SUM(usage_quantity) as total_usage_quantity,
  SUM(CASE WHEN usage_metadata.job_run_id != origin_job_run_id THEN usage_quantity ELSE 0 END) AS workflow_run_usage_quantity,
  COUNT(DISTINCT usage_metadata.job_run_id) - 1 AS workflow_runs
FROM billing_logs_enriched
GROUP BY ALL

Calculer le coût par exécution du travail

Cette requête se joint à la table système billing.usage pour calculer un coût par exécution de tâche.

with jobs_usage AS (
  SELECT
    *,
    usage_metadata.job_id,
    usage_metadata.job_run_id as run_id,
    identity_metadata.run_as as run_as
  FROM system.billing.usage
  WHERE billing_origin_product="JOBS"
),
jobs_usage_with_usd AS (
  SELECT
    jobs_usage.*,
    usage_quantity * pricing.default as usage_usd
  FROM jobs_usage
    LEFT JOIN system.billing.list_prices pricing ON
      jobs_usage.sku_name = pricing.sku_name
      AND pricing.price_start_time <= jobs_usage.usage_start_time
      AND (pricing.price_end_time >= jobs_usage.usage_start_time OR pricing.price_end_time IS NULL)
      AND pricing.currency_code="USD"
),
jobs_usage_aggregated AS (
  SELECT
    workspace_id,
    job_id,
    run_id,
    FIRST(run_as, TRUE) as run_as,
    sku_name,
    SUM(usage_usd) as usage_usd,
    SUM(usage_quantity) as usage_quantity
  FROM jobs_usage_with_usd
  GROUP BY ALL
)
SELECT
  t1.*,
  MIN(period_start_time) as run_start_time,
  MAX(period_end_time) as run_end_time,
  FIRST(result_state, TRUE) as result_state
FROM jobs_usage_aggregated t1
  LEFT JOIN system.lakeflow.job_run_timeline t2 USING (workspace_id, job_id, run_id)
GROUP BY ALL
ORDER BY usage_usd DESC
LIMIT 100

Obtenir les journaux d’utilisation d’un travail SUBMIT_RUN

SELECT
  *
FROM system.billing.usage
WHERE
  EXISTS (
      SELECT 1
      FROM system.lakeflow.job_run_timeline
      WHERE
        job_run_timeline.job_id = usage_metadata.job_id
        AND run_name = :run_name
        AND workspace_id = :workspace_id
  )

Joindre les tables de chronologie d’exécution de tâches de travaux et de clusters

Enrichir les exécutions de tâches avec les métadonnées des clusters

with clusters as (
    SELECT
        *,
        ROW_NUMBER() OVER (PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) as rn
    FROM system.compute.clusters QUALIFY rn=1
),
exploded_task_runs AS (
  SELECT
    *,
    EXPLODE(compute_ids) as cluster_id
  FROM system.lakeflow.job_task_run_timeline
  WHERE array_size(compute_ids) > 0
)
SELECT
  *
FROM exploded_task_runs t1
  LEFT JOIN clusters t2
    USING (workspace_id, cluster_id)

Rechercher les travaux en cours d’exécution sur le calcul à usage général

Cette requête s’associe à la table système compute.clusters pour renvoyer les travaux récents exécutés sur le calcul à usage général au lieu du calcul des travaux.

with clusters AS (
  SELECT
    *,
    ROW_NUMBER() OVER(PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) as rn
  FROM system.compute.clusters
  WHERE cluster_source="UI" OR cluster_source="API"
  QUALIFY rn=1
),
job_tasks_exploded AS (
  SELECT
    workspace_id,
    job_id,
    EXPLODE(compute_ids) as cluster_id
  FROM system.lakeflow.job_task_run_timeline
  WHERE period_start_time >= CURRENT_DATE() - INTERVAL 30 DAY
  GROUP BY ALL
),
all_purpose_cluster_jobs AS (
  SELECT
    t1.*,
    t2.cluster_name,
    t2.owned_by,
    t2.dbr_version
  FROM job_tasks_exploded t1
    INNER JOIN clusters t2 USING (workspace_id, cluster_id)
)
SELECT * FROM all_purpose_cluster_jobs LIMIT 10;

Rechercher des travaux qui n’ont pas été exécutés au cours des 30 derniers jours

Cette requête joint les tables système et lakeflow.jobs les lakeflow.job_run_timeline tables système pour retourner des travaux qui n’ont pas été exécutés au cours des 30 derniers jours.

with latest_jobs AS (
    SELECT
        *,
        ROW_NUMBER() OVER (PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
    FROM system.lakeflow.jobs QUALIFY rn=1
),
latest_not_deleted_jobs AS (
    SELECT
        workspace_id,
        job_id,
        name,
        change_time,
        tags
    FROM latest_jobs WHERE delete_time IS NULL
),
last_seen_job_timestamp AS (
    SELECT
        workspace_id,
        job_id,
        MAX(period_start_time) as last_executed_at
    FROM system.lakeflow.job_run_timeline
    WHERE
        run_type="JOB_RUN"
    GROUP BY ALL
)
SELECT
    t1.workspace_id,
    t1.job_id,
    t1.name,
    t1.change_time as last_modified_at,
    t2.last_executed_at,
    t1.tags
FROM latest_not_deleted_jobs t1
    LEFT JOIN last_seen_job_timestamp t2
        USING (workspace_id, job_id)
WHERE
    (t2.last_executed_at <= CURRENT_DATE() - INTERVAL 30 DAYS) OR (t2.last_executed_at IS NULL)
ORDER BY last_executed_at ASC

Tableau de bord de surveillance des emplois

Le tableau de bord ci-après utilise des tables système pour vous aider à débuter la surveillance de vos travaux et de la santé opérationnelle. Il inclut des cas d’usage courants tels que le suivi des performances des travaux, la surveillance des défaillances et l’utilisation des ressources.

Pour plus d’informations sur le téléchargement du tableau de bord, consultez Surveiller les coûts & les performances des travaux avec les tables système

Troubleshooting

La tâche n'est pas consignée dans la table lakeflow.jobs

Si un travail n’est pas visible dans les tables système :

• Le travail n’a pas été modifié au cours des 365 derniers jours
  • Modifier tous les champs du travail présents dans le schéma afin d'émettre un nouvel enregistrement.
• Le travail a été créé dans une autre région
• Création récente d’emploi (décalage dans les données)

Impossible de trouver un travail affiché dans la job_run_timeline table

Toutes les exécutions des travaux ne sont pas visibles partout. Bien que les entrées JOB_RUN apparaissent dans toutes les tables liées aux travaux, les WORKFLOW_RUN (exécutions de workflows de notebooks) sont enregistrées seulement dans job_run_timeline et les SUBMIT_RUN (exécutions soumises une seule fois) sont enregistrées seulement dans les deux tables de chronologie. Ces exécutions ne sont pas renseignées dans d’autres tables système des travaux, comme jobs ou job_tasks.

Consultez le tableau Des types d’exécution ci-dessous pour obtenir une répartition détaillée des emplacements où chaque type d’exécution est visible et accessible.

Exécution de travail non visible dans la table billing.usage

Dans system.billing.usage, le usage_metadata.job_id est renseigné seulement pour les tâches qui s’exécutent sur le calcul des travaux ou sur le calcul serverless.

En outre, les travaux WORKFLOW_RUN n’ont pas leur propre attribution de usage_metadata.job_id ou de usage_metadata.job_run_id dans system.billing.usage. Au lieu de cela, leur utilisation des ressources de calcul est attribuée au bloc-notes parent qui l'a déclenchée. Cela signifie que lorsqu’un notebook lance une exécution de flux de travail, tous les coûts de calcul apparaissent sous l’utilisation du notebook parent, et non en tant que travail de flux de travail distinct.

Pour plus d’informations, consultez la référence d'utilisation des métadonnées .

Calculer le coût d’un travail s'exécutant sur un calculateur polyvalent

Le calcul précis des coûts pour les travaux exécutés sur un calcul dédié n’est pas possible avec une précision de 100 %. Lorsqu’un travail s’exécute sur un calcul interactif (à usage unique), plusieurs charges de travail telles que des notebooks, des requêtes SQL ou d’autres travaux s’exécutent souvent simultanément sur cette même ressource de calcul. Étant donné que les ressources de cluster sont partagées, il n’existe aucun mappage direct 1:1 entre les coûts de calcul et les exécutions de travaux individuelles.

Pour un suivi précis des coûts des travaux, Databricks recommande d’exécuter les travaux sur des calculs de travaux dédiés ou sur un calcul serverless, où le usage_metadata.job_id et le usage_metadata.job_run_id permettent une attribution précise des coûts.

Si vous devez utiliser le calcul à usage unique, vous pouvez :

• Surveillez l’utilisation globale du cluster et les coûts dans system.billing.usage en fonction de usage_metadata.cluster_id.
• Suivez séparément les métriques de temps d'exécution des tâches.
• Considérez que toute estimation des coûts sera approximative en raison des ressources partagées.

Consultez la référence de la métadonnée d'utilisation pour obtenir plus d'informations sur l’attribution des coûts.

Valeurs de référence

La section suivante inclut des références pour sélectionner des colonnes dans des tables liées aux travaux.

Logique de découpage dans les tables de chronologie

Les colonnes period_start_time et period_end_time dans les tables job_run_timeline et job_task_run_timeline enregistrent la période active d’une exécution de travail ou d’une exécution de tâche.

:::warning Important change

À compter du 19 janvier 2026, les nouvelles lignes émises dans les tables de chronologie utilisent une logique de découpage alignée sur l’heure d’horloge. Les lignes existantes resteront inchangées.

Les tranches sont créées à intervalles d'une heure, en fonction de l'heure de démarrage de l'exécution. Par exemple, un travail commençant à 16 h 47 crée des tranches de 16 h 47 à 17 h 47, de 17 h 47 à 18 h 47, et ainsi de suite.

Les tranches s’alignent sur les limites de l’heure de l’horloge. Par exemple, un travail commençant à 16 h 47 créera des tranches de 16 h 47 à 17 h 00, 17 h 00 à 18 h 00, 18 h 00 à 19 h 00, et ainsi de suite. Pour plus d’informations, consultez la logique de découpage alignée sur l’heure de l’horloge .

:::

Chaque ligne enregistre jusqu’à une heure de fonctionnement. Les exécutions qui durent plus d'une heure sont enregistrées sur plusieurs lignes. Ce découpage garantit une granularité horaire pour la surveillance des travaux de longue durée.

Travaux courts

Pour les exécutions de moins d'une heure, une seule ligne est émise, avec period_start_time réglé sur l'heure de début de l'exécution et period_end_time sur l'heure de fin de l'exécution.

Par exemple, un travail a démarré à 12h13 UTC et s’est terminé à 12h45 UTC est représenté par une seule ligne :

Travaux de longue durée

Pour les exécutions qui durent plus de 1 heure, plusieurs lignes sont émises avec le même run_id, chacune représentant jusqu’à une heure de la durée de l’exécution :

• La première ligne commence à l’heure de début réelle de l’exécution et se termine à la fin de la première heure d’exécution.
• Les lignes intermédiaires (le cas échéant) s’étendent sur les fenêtres horaires complètes, alignées sur la tranche period_end_timeprécédente.
• La dernière ligne commence au début de la tranche précédente et se termine à l'heure de fin effective de l'exécution.

Par exemple, un travail exécuté de 17h47 UTC à 18h28 UTC est segmenté en plusieurs lignes. Chaque ligne représente une heure d’activité, à l’exception de la dernière ligne, qui peut être plus courte :

Logique de découpage alignée sur l’heure de l’horloge

À compter du 19 janvier 2026, les tables de chronologie utilisent le découpage aligné sur l’heure de l’horloge. Toutes les tranches de temps s’alignent sur les limites d’heure d’horloge standard.

Pour les exécutions de travaux de moins d'une heure qui commencent et se terminent dans la même heure, une seule ligne est générée:

Pour les exécutions de travaux qui dépassent les limites d’heure d’horloge, plusieurs lignes sont émises avec des tranches alignées sur les heures d’horloge :

• La première ligne commence à l’heure de début réelle de l’exécution et se termine à la limite de l’heure d’horloge suivante.
• Les lignes intermédiaires (le cas échéant) s’étendent sur les heures d’horloge complètes. Par exemple : 14:00-15:00 et 15:00-16:00.
• La dernière ligne commence à une limite horaire et se termine à l'heure de fin réelle du processus.

Par exemple, une tâche exécutée de 1:25 UTC à 3:40 UTC est découpée en trois lignes :

Valeurs du type de déclencheur

Dans le job_run_timeline tableau, les valeurs possibles pour la trigger_type colonne sont les suivantes :

• CONTINUOUS
• CRON
• FILE_ARRIVAL
• ONETIME
• ONETIME_RETRY

Valeurs du type d’exécution

Dans le job_run_timeline tableau, les valeurs possibles pour la run_type colonne sont les suivantes :

Valeurs d’état de résultat

Dans les tables job_task_run_timeline et job_run_timeline, les valeurs possibles pour la colonne result_state sont les suivantes :

Valeurs de code d’arrêt

Dans les tables job_task_run_timeline et job_run_timeline, les valeurs possibles pour la colonne termination_code sont les suivantes :

Valeurs de type de pipeline

Dans le pipelines tableau, les valeurs possibles pour la pipeline_type colonne sont les suivantes :

Informations de référence sur les résultats du pipeline

Dans le pipeline_update_timeline tableau, les valeurs possibles pour la result_state colonne sont les suivantes :

• COMPLETED
• FAILED
• CANCELED

Informations de référence sur les paramètres du pipeline

Dans le pipelines tableau, les valeurs possibles pour la settings colonne sont les suivantes :

Valeurs de type de mise à jour du pipeline

Dans le pipeline_update_timeline tableau, les valeurs possibles pour la update_type colonne sont les suivantes :

• API_CALL
• RETRY_ON_FAILURE
• SERVICE_UPGRADE
• SCHEMA_CHANGE
• JOB_TASK
• USER_ACTION
• DBSQL_REQUEST
• SETTINGS_CHANGE
• SCHEMA_EXPLORATION
• INFRASTRUCTURE_MAINTENANCE
• START_RESOURCES

Valeurs de type de déclencheur de pipeline

Dans le pipeline_update_timeline tableau, les valeurs possibles pour la trigger_type colonne sont les suivantes :

Détails du type de déclencheur de pipeline

Dans la pipeline_update_timeline table, les valeurs possibles pour le trigger_type.job_task struct sont les suivantes :