Création de demandes de changement avec des erreurs de récupération de données DevOps

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 6 minutes de lecture

    • Créez des demandes de changement, même avec des erreurs de récupération de données DevOps.

    Vue d'ensemble de la création de demandes de changement

    Remarque :
    La création d’une demande de changement avec erreurs de récupération de données DevOps n’est prise en charge que pour Azure DevOps les pipelines , GitHub Actions, GitLabJenkins, et Harnais.

    Vous pouvez créer une demande de changement avec ou sans erreurs de récupération de données DevOps. Vous pouvez contrôler cette fonctionnalité via la propriété Activer la création de demandes de changement, même avec des erreurs dans la récupération de données DevOps. Lorsque la propriété Activer la création de demandes de changement, même avec des erreurs dans la récupération de données DevOps est activée et qu'une erreur se produit lors de la récupération de données DevOps telles que les éléments de travail, les validations, les résumés de tests ou les résumés de sécurité, la demande de changement correspondante est quand même créée. Les données pouvant être récupérées sont toujours associées à la demande de changement. Si les données sont impossibles à récupérer, le motif de l'erreur est notifié à l'utilisateur dans la console tierce, et les mêmes informations sont ajoutées au champ Commentaires sur le changement dans l'enregistrement d'exécution d'étape et dans les notes de travail du changement.

    Si la propriété Activer la création de demandes de changement, même avec des erreurs dans la récupération de données DevOps n'est pas activée, une demande de changement est créée uniquement si aucune étape d'exécution de pipeline ne présente d'erreur. Si une erreur se produit, le pipeline est abandonné et le motif de l'erreur est ajouté au champ Détails du traitement de l'événement entrant, puis notifié à l'utilisateur dans la console tierce.

    Pour plus d'informations, consultez Propriétés du Vélocité de changement DevOps.

    Approbation des demandes de changement avec des erreurs de récupération de données DevOps

    Pour les demandes de changement créées avec des erreurs de récupération de données DevOps, l'entrée de politique is_change_with_partial_data est définie sur True pour toutes les politiques d'approbation de changement. Seule une décision d'approbation de changement manuelle est appliquée à ces changements afin que vous puissiez approuver ou rejeter le changement après avoir vérifié manuellement les données DevOps qu'il contient. Dans le flux secondaire Collecte des données de politique de changement DevOps, l'action Is change with partial data détermine si un changement est créé avec des erreurs de récupération de données DevOps ou non.

    Interface utilisateur du pipeline pour les demandes de changement avec des erreurs de récupération de données DevOps

    Lorsqu'une demande de changement est créée avec des erreurs de récupération de données DevOps, la carte spécifiant l'étape où l'erreur s'est produite s'affiche en jaune. Interface utilisateur du pipeline affichant la carte d'étape d'erreur en jaune pour les changements comportant des erreurs

    Remarque :
    Si votre pipeline de version (CI) est configuré pour déclencher un pipeline de mise en production (CD) et qu'un changement est créé dans le pipeline de mise en production, les données sont collectées à partir du pipeline de version et associées à la demande de changement. Il peut arriver que le module Vélocité de changement DevOps ServiceNow reçoive et traite les événements de pipeline de mise en production avant les événements de pipeline de version. Dans ce cas, le changement est créé avec les données DevOps du pipeline de version, même si aucune erreur ne se produit lors de la récupération de certaines données. Vous observez ce comportement même si la propriété Activer la création de demandes de changement, même avec des erreurs dans la récupération de données DevOps est activée. En outre, l'entrée de politique is_change_with_partial_data est définie sur False dans ce cas, et le processus d'approbation est appliqué selon le paramètre défini dans les flux d'approbation (et non plus selon le paramètre Toujours manuel) en cas de demandes de changement avec des erreurs de récupération de données DevOps.

    Délai d'expiration des rappels

    Si un événement entrant passe à l'état En attente pendant une exécution de pipeline, le système tente de traiter le changement jusqu'à ce que la valeur du délai d'expiration de la propriété sn_devops.change _request_callback_timeout soit dépassée, après quoi le pipeline est abandonné. Le motif de l'erreur s'affiche dans les journaux de la console de votre outil tiers. Lorsqu'un pipeline est annulé en raison d'un délai d'expiration du rappel, les mêmes informations sont ajoutées à l'enregistrement de rappel de l'exécution d'étape correspondante. Vous pouvez contacter l'administrateur DevOps pour augmenter la valeur du délai d'expiration de la propriété sn_devops.change_request_callback_timeout. La valeur par défaut de cette propriété est de 120 minutes et la valeur minimale de 60 minutes. Pour plus d'informations, consultez Propriétés du Vélocité de changement DevOps.

    Remarque :
    Si vous utilisez l’action personnalisée d’automatisation des changements GitHub, l’action personnalisée d’automatisation des changements GitLab Docker ou l’action personnalisée d’automatisation des changements Harness Docker dans votre pipeline correspondant pour créer des demandes de changement, vous devez fournir l’intervalle dans l’action personnalisée, ce qui permet à GitHub, GitLab ou Harness d’interroger ServiceNow DevOps pour connaître l’état du changement. Lorsque le changement atteint un état approprié dans ServiceNow dans l’intervalle spécifié, l’état approprié, en fonction du résultat du changement, est envoyé au pipeline GitHub, GitLab ou Harness, qui reprend ou abandonne le pipeline. Consultez Actions personnalisées ServiceNow DevOps de la place de marché GitHub et Implémenter des actions personnalisées pour les pipelines utilisant une image de conteneur Docker générique pour plus de détails. Ainsi, lorsque votre pipeline avec l’action personnalisée de changement est exécuté, et si l’une des notifications d’étapes de GitHub, GitLab ou Harness n’a pas atteint ServiceNow DevOps, l’association du rappel, de l’exécution d’étape et de l’exécution de la tâche ne se produit pas dans ServiceNow DevOps. Étant donné que l'association n'est pas disponible, le changement n'est pas créé et ServiceNow DevOps attend que l'association soit en place. Dans le même temps, GitHub, GitLab ou Harness interroge ServiceNow pour connaître l’état du changement jusqu’à ce que l’heure spécifiée dans l’intervalle soit atteinte. Si l’intervalle est dépassé et que le délai d’expiration spécifié dans la sn_devops.change_request_callback_timeout propriété est atteint, ServiceNow DevOps ne mettra pas fin à votre pipeline comme il le devrait, mais le laissera pour le délai d’expiration par défaut défini dans l’étape GitHub, GitLab ou Harness qui mettra fin au pipeline. L’information importante dans ce scénario est que ServiceNow DevOps ne sera pas en mesure de notifier l’utilisateur que les événements d’étape n’ont pas atteint ServiceNow DevOps dans les journaux de la console GitHub, GitLab ou Harness.

    Mise à niveau

    Après la mise à niveau, la propriété est définie sur false par défaut. Votre processus de changement actuel fonctionne tel quel, la seule différence étant que, lorsqu'une erreur se produit lors de la récupération de données DevOps, le pipeline est abandonné (au lieu d'attendre indéfiniment), et le motif de l'erreur est ajouté au champ Détails du traitement de l'événement entrant et notifié à l'utilisateur dans la console tierce. Si vous souhaitez créer des demandes de changement comportant des erreurs de récupération de données DevOps sans faire échouer votre pipeline, vous pouvez activer la propriété Activer la création de demandes de changement, même avec des erreurs dans la récupération de données DevOps. Vous fournissez ainsi des informations supplémentaires à vos approbateurs de changement et à vos équipes AppDev en créant automatiquement des changements grâce aux preuves DevOps recueillies et notifiées de manière appropriée dans les notes de travail de la demande de changement et les journaux de la console tierce contenant des erreurs ou des données qui peuvent être manquantes.

    Limitation

    Si la propriété Activer la création de demandes de changement, même avec des erreurs dans la récupération de données DevOps est activée et que l'étape de package d'artefact ADO dans votre pipeline entraîne une erreur, le changement est créé sans artefacts ADO associés, mais l'erreur correspondante n'est pas notifiée dans les notes de travail, les commentaires sur le changement d'exécution d'étape ou le journal de la console ADO.