--- sourceDocument: Yokohama Gestão de serviços de TI sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/yokohama/it-service-management Release : - yokohama ft:locale : - pt-BR ft:publication_title : - Yokohama Gestão de serviços de TI ft:clusterId : - itsm bundleId : - itsm workflow : - Technology --- # Criação de solicitação de mudança com erros de recuperação de dados DevOps # Criação de solicitação de mudança com erros de recuperação de dados DevOps {#ariaid-title1} * Versão de lançamento: Yokohama * * Atualizado 30 de jan. de 2025 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 min. de leitura Crie solicitações de mudança mesmo com erros na recuperação de dados de DevOps. ## Visão geral da criação de solicitação de mudança {#change-request-creation-with-devops-data-retrieval-errors__section_vtc_3qz_2bc} Nota: A criação de solicitação de mudança com erros de recuperação de dados DevOps é compatível somente para Azure DevOps, GitHub Actions, GitLabe. Jenkinspipelines. Você pode criar uma solicitação de mudança com ou sem erros na recuperação de dados de DevOps. Esta funcionalidade pode ser controlada pelo Ative a criação de solicitação de mudança mesmo com erros na recuperação de dados de DevOps propriedade. Quando o. Ative a criação de solicitação de mudança mesmo com erros na recuperação de dados de DevOps A propriedade está habilitada e ocorre um erro ao recuperar dados de DevOps, como itens de trabalho, confirmações, resumos de testes ou resumos de segurança, a solicitação de mudança correspondente ainda é criada. Os dados que podem ser recuperados ainda serão associados à solicitação de mudança. Para os dados que não podem ser recuperados, o motivo do erro será notificado ao usuário no console de terceiros e as mesmas informações também serão adicionadas ao Comentários de mudança No registro de Execução de etapa e na mudança Anotações de trabalho . . Ative a criação de solicitação de mudança mesmo com erros na recuperação de dados de DevOps a propriedade não está habilitada, uma solicitação de mudança é criada somente quando não há erro em nenhuma etapa de uma execução de pipeline. Quando ocorre um erro, o pipeline é abortado e o motivo do erro é adicionado nos eventos de entrada Processando detalhes e o mesmo é notificado ao usuário no console de terceiros. Para obter mais informações, consulte [Propriedades Velocidade de mudança para DevOps](https://servicenow-prod.fluidtopics.net/jIgeu_J4Lgp7DOhm6wl7PQ "Use essas propriedades para definir configurações no Velocidade de mudança para DevOpsaplicação."). ## Aprovação de solicitações de mudança com erros de recuperação de dados DevOps {#change-request-creation-with-devops-data-retrieval-errors__section_cxs_mqz_2bc} Para solicitações de mudança criadas com erros de recuperação de dados DevOps, o. is_change_with_partial_dataa entrada de política está definida como Verdadeiro para todas as políticas de aprovação de mudança. Somente uma decisão de aprovação de mudança manual é aplicada a essas mudanças para que você possa aprovar ou rejeitar a mudança depois de verificar manualmente os dados de DevOps nela. No subfluxo de coleta de dados da política de mudança de DevOps, o. Is change with partial dataA ação determina se uma mudança é criada com erros de recuperação de dados de DevOps ou não. ## IU do pipeline para solicitações de mudança com erros de recuperação de dados de DevOps {#change-request-creation-with-devops-data-retrieval-errors__section_sfn_4qz_2bc} Quando uma solicitação de mudança é criada com erros de recuperação de dados de DevOps, o cartão que especifica a fase em que o erro ocorreu será exibido na cor amarela. Nota: Se o pipeline de compilação (IC) estiver configurado para acionar um pipeline de versão (CD) e uma mudança for criada no pipeline de versão, os dados serão coletados do pipeline de compilação e associados à solicitação de mudança. Pode haver uma situação em que a Velocidade de mudança do DevOps da ServiceNow receba e processe os eventos de pipeline de versão antes de criar eventos de pipeline. Nesse caso, a mudança será criada com os dados de DevOps do pipeline de compilação, mesmo que haja um erro ao recuperar alguns dos dados. Você pode observar esse comportamento mesmo em Ative a criação de solicitação de mudança mesmo com erros na recuperação de dados de DevOps a propriedade está habilitada. . is_change_with_partial_dataA entrada de política será falsa nesse caso, e o processo de aprovação será aplicado da maneira definida nos fluxos de aprovação, ao contrário de sempre manual no caso de solicitações de mudança com erros de recuperação de dados de DevOps. ## Tempo limite de retorno de chamada {#change-request-creation-with-devops-data-retrieval-errors__section_rnm_zqz_2bc} Se um evento de entrada entrar no estado Aguardando durante uma execução de pipeline, o sistema tentará processar a mudança até o valor de tempo limite no sn_devops.change _request_callback_timeouta propriedade foi excedida, depois que o pipeline é anulado. O motivo do erro é exibido nos logs do console da ferramenta de terceiros. Quando um pipeline é cancelado devido ao tempo limite de retorno de chamada, as mesmas informações são adicionadas ao registro de retorno de chamada da execução da etapa correspondente. Você pode entrar em contato com o administrador de DevOps para aumentar o valor do tempo limite no sn_devops.change_request_callback_timeoutpropriedade. O valor padrão desta propriedade é 120 minutos e o valor mínimo é 60 minutos. Para obter mais informações, consulte [Propriedades Velocidade de mudança para DevOps](https://servicenow-prod.fluidtopics.net/jIgeu_J4Lgp7DOhm6wl7PQ "Use essas propriedades para definir configurações no Velocidade de mudança para DevOpsaplicação."). Nota: Se você estiver usando a ação personalizada de automação de mudanças do GitHub ou a ação personalizada de automação de mudanças do Docker do GitLab no pipeline correspondente para criar solicitações de mudança, será necessário fornecer o. intervalo Na ação personalizada, que permite que o GitHub ou GitLab pesquise o status de mudança DevOps da ServiceNow. Quando a mudança atingir um estado apropriado na ServiceNow dentro do intervalo especificado, o status apropriado, dependendo do resultado da mudança, será enviado para o pipeline do GitHub ou GitLab, que retomará ou abortará o pipeline. Consulte [Ações personalizadas da ServiceNow DevOps do GitHub marketplace](https://servicenow-prod.fluidtopics.net/GFmMK1iOJgcYgkoD_jBrbg#servicenow-devops-custom-actions-from-github-marketplace "Use as ações personalizadas do GitHubMarketplace para coletar dados de verificação do SonarQube, dados de segurança, pausar ou retomar o fluxo de trabalho ou retomar o fluxo de trabalho até que uma solicitação de mudança seja aprovada ou rejeitada em sua instância, ou obter e atualizar detalhes da solicitação de mudança e assim por diante.")e. [Implemente ações personalizadas para pipelines usando a imagem genérica do contêiner do Docker](https://servicenow-prod.fluidtopics.net/ueS~xh_cYc4qZaUrbZ_UGw "Use o. ServiceNowAções personalizadas para coletar dados relacionados à criação de solicitação de mudança, verificação do sonar, registro de artefato e registro de pacote em seu pipeline com a ajuda do genérico DockerImagem do contêiner.")para obter mais detalhes. Portanto, quando seu pipeline com a ação personalizada de mudança for executado e se alguma notificação de etapa do GitHub ou GitLab não chegar ao DevOps da ServiceNow, a associação de retorno de chamada, execução de etapa e execução de tarefa não acontecerá no DevOps da ServiceNow. Como a associação não está disponível, a mudança não será criada e a ServiceNow DevOps aguardará até que a associação esteja em vigor. Ao mesmo tempo, o GitHub ou GitLab pesquisará a ServiceNow para obter o status de mudança até que o tempo especificado no intervalo seja atingido. Se o intervalo for passado e também o tempo limite especificado no sn_devops.change_request_callback_timeoutA propriedade foi atingida, a ServiceNow DevOps não encerrará seu pipeline como deveria, mas o deixará pelo tempo limite padrão definido na etapa GitHub ou GitLab que, eventualmente, encerrará o pipeline. A informação importante neste cenário é que a ServiceNow DevOps não poderá notificar o usuário de que os eventos de etapa não atingiram a ServiceNow DevOps nos logs do console GitHub ou GitLab. ## Upgrade {#change-request-creation-with-devops-data-retrieval-errors__section_kqx_lrz_2bc} Após o upgrade, a propriedade será definida como falsa por padrão. Seu processo de mudança atual funcionará como está, mas a única diferença que você verá é que, quando ocorre um erro na recuperação de dados de DevOps, o pipeline é abortado (em vez de esperar indefinidamente) e o motivo do erro é adicionado ao evento de entrada Processando detalhes e o mesmo é notificado ao usuário no console de terceiros. Se você quiser criar solicitações de mudança com erros na recuperação de dados de DevOps e também não falhar no pipeline, habilite o. Ative a criação de solicitação de mudança mesmo com erros na recuperação de dados de DevOps propriedade. Isso agrega valor aos aprovadores de mudança e às equipes de AppDev, obtendo as mudanças criadas automaticamente com evidências de DevOps coletadas e devidamente notificadas nas anotações de trabalho de solicitação de mudança e logs de console de terceiros com erros ou dados que podem estar ausentes. ## Limitação {#change-request-creation-with-devops-data-retrieval-errors__section_phq_5rz_2bc} . Ative a criação de solicitação de mudança mesmo com erros na recuperação de dados de DevOps A propriedade está habilitada e a etapa do pacote de artefatos ADO no pipeline resulta em erro. A mudança será criada sem artefatos ADO associados a ela, mas o erro correspondente não será notificado nos Anotes de trabalho, nos comentários de mudança de execução de etapa ou no log do console ADO.