В этом материале
Корректный JSON не доказывает выполнение всех тестов: сохраняйте статус процесса, результаты проверок и версию производителя данных.
Структурированному выводу тоже нужен контракт
JSON является форматом передачи, а не обещанием одинакового документа во всех будущих выпусках диагностики. Автоматизация DCGM должна сохранять версию производителя данных, выбранную команду и режим вывода до интерпретации результата. Парсер, который молча принимает пустой документ за успех, ошибается в отчётности оборудования, даже если никогда не падает.
В справочнике диагностики dcgmi описаны поддерживаемый запуск и вывод текущего выпуска. Эти детали нужно считать зависимыми от версии. Закрепите диагностическую среду конвейера приёмки и проверяйте парсер на сохранённых результатах именно этого производителя данных.
Сохраняйте окружение процесса
Отдельно записывайте код завершения, стандартный вывод, поток ошибок, время начала, длительность и идентификаторы выбранных устройств. Команда, которая не смогла инициализировать зависимость, не даёт тех же свидетельств, что завершившийся тест оборудования. Аналогично, возможность разобрать JSON ещё не устанавливает выполнение всех запрошенных проверок.
Руководство DCGM по диагностике объясняет место запуска в эксплуатационном процессе и ограничения совместимости вывода. Если долгоживущей интеграции нужна устойчивая программная граница, следует рассмотреть документированные API вместо предположения, что JSON командной строки имеет бессрочно стабильную схему.
Разделяйте категории результатов
Для каждого выбранного устройства и теста сохраняйте исходный статус и нормализованную внутреннюю категорию. Успешное выполнение, обнаруженный отказ, пропуск, прерывание и неизвестный либо неразобранный вывод требуют разных категорий. Точное написание и вложенность берутся из закреплённого выпуска, а не из правдоподобного примера, придуманного разработчиком парсера.
Пропущенный тест не является успешным. Пропуск может отражать применимость, отсутствие предпосылок или решение выбранного набора. Сохраняйте сопровождающую причину, если она есть. Отсутствие обязательной проверки должно препятствовать заявлению о завершении плана, даже когда выполненная часть тестов имеет благоприятные результаты.
Проверьте парсер небольшими примерами
Подготовьте сохранённые примеры ожидаемого успеха, отказа, пропуска, отсутствующего обязательного поля, нового дополнительного поля и обрезанного вывода. Добавьте ошибку самого процесса без полного результата. Такие примеры проверяют потребителя данных без запуска инвазивной диагностики при каждом изменении программного обеспечения.
Например, новое необязательное поле метаданных не должно автоматически отменять понятный результат. Но отсутствие идентификатора устройства не должно прикреплять тест к первой GPU инвентаризации. Документируйте обязательные поля и передачу неизвестного статуса на разбор, вместо его преобразования в успех ради завершения конвейера.
Публикуйте ограниченный результат приёмки
Итоговый документ перечисляет запрошенные и выполненные проверки, пропуски, отказы, версию парсера и исходный вывод производителя. Храните первичные свидетельства рядом с нормализованной сводкой, чтобы будущий парсер мог прочитать их заново. Успех разбора устанавливает понятность записи; успех диагностики относится только к выбранным тестам и условиям выполнения.
При смене DCGM сначала прогоняйте сохранённые примеры и реальные результаты новой версии через проверяемый потребитель. Только после этого меняйте закреплённую среду и явно отмечайте новую границу совместимости в истории приёмки узлов.