El sitio Datadog seleccionado () no es compatible.
Nota: Datadog recomienda la instrumentación nativa de los tests sobre la carga de archivos XML JUnit,
ya que la instrumentación nativa proporciona resultados de tiempo más precisos, admite trazas distribuidas en tests de integraciones
y otras características que no están disponibles con las cargas XML JUnit.
Para obtener más detalles, consulte la tabla Características compatibles.
Información general
Los archivos de informes de tests de JUnit son archivos XML que contienen información sobre la ejecución de los tests, como los nombres de tests y conjuntos, los estados aprobado o fallido, la duración y, en ocasiones, los logs de error. Aunque fue introducido por el marco para tests JUnit, muchos otros marcos populares son capaces de generar resultados utilizando este formato.
Si tu marco para tests puede generar informes de tests XML de JUnit, puedes utilizarlos como una alternativa ligera a la instrumentación de tus pruebas de forma nativa utilizando rastreadores Datadog. Los resultados de los tests importados de informes XML de JUnit aparecen junto a los datos de los tests notificados por los rastreadores.
Compatibilidad
Biblioteca de rastreo de Datadog compatible:
Biblioteca de Datadog
Versión
datadog-ci
2.17.0 o anterior
Instalación de la CLI de Datadog CI
Instala la CLI de datadog-ci globalmente utilizando npm:
npm install -g @datadog/datadog-ci
Binario independiente (Beta)
Nota: Los binarios independientes están en fase beta y su estabilidad no está garantizada.
Si la instalación de Node.js en el CI es un problema, se proporcionan binarios independientes con las versiones de Datadog CI. Sólo son compatibles linux-x64, darwin-x64, (MacOS) y win-x64 (Windows). Para instalarlos, ejecuta lo siguiente en tu terminal:
Para cargar tus informes de tests XML de JUnit en Datadog, ejecuta el siguiente comando, especificando el nombre de servicio o biblioteca al que se realizó un test, utilizando el parámetro --servicio y una o más rutas de archivo a los archivos de informes XML directamente o a los directorios que los contienen:
Especifica una clave de API de Datadog válida en la variable de entorno DATADOG_API_KEY entorno y el entorno donde se han ejecutado los tests (por ejemplo, local, cuando se cargan los resultados desde una estación de trabajo de desarrollador, o ci, cuando se cargan desde un proveedor de CI) en la variable de entorno DD_ENV. Por ejemplo:
Asegúrate de que este comando se ejecuta en tu CI, incluso si tus tests han fallado. Normalmente, cuando los tests fallan, la tarea CI aborta la ejecución y el comando de carga no se ejecuta.
pasos:- nombre:Ejecutar testsejecutar:./run-tests.sh- nombre:Cargar los resultados de los tests en Datadogsi:siempre()ejecutar:datadog-ci junit upload --service service_name ./junit.xml
Es posible que los informes de más de 250 MB no se procesen por completo, por lo que podrían faltar tests o logs. Para disfrutar de la mejor experiencia, asegúrate de que los informes sean inferiores a 250 MiB.
Parámetros de configuración
Esta es la lista completa de opciones disponibles cuando se utiliza el comando datadog-ci junit upload:
--service (Requerido)
Nombre del servicio o de la biblioteca a los que se realizan tests. Variable de entorno: DD_SERVICE Ejemplo: my-api-service
--env
Entorno donde se han ejecutado los tests. Variable de entorno: DD_ENV Ejemplo: ci
--tags
Pares clave-valor con el formato key:value que se adjuntarán a todos los tests (el parámetro --tags se puede especificar varias veces). Cuando se especifican etiquetas utilizando DD_TAGS, sepáralas con comas (por ejemplo, team:backend,priority:high). Variable de entorno: DD_TAGS Por defecto: (ninguno) Ejemplo: team:backend Nota: Las etiquetas especificadas utilizando --tags y la variable de entorno DD_TAGS se combinan. Si aparece la misma clave tanto en --tags como en DD_TAGS, el valor en la variable de entorno DD_TAGS tiene prioridad.
--measures
Pares numéricos clave-valor con el formato key:number que se adjuntarán a todos los tests (el parámetro --measures se puede especificar varias veces). Cuando se especifican medidas utilizando DD_MEASURES, sepáralas con comas (por ejemplo, memory_allocations:13,test_importance:2). Variable de entorno: DD_MEASURES Por defecto: (ninguno) Ejemplo: memory_allocations:13 Nota: Las medidas especificadas utilizando --measures y la variable de entorno DD_MEASURES se combinan. Si aparece la misma clave tanto en --measures como en DD_MEASURES, el valor en la variable de entorno DD_MEASURES tienen prioridad.
--report-tags
Pares clave-valor con el formato key:value. Funciona como el parámetro --tags pero estas etiquetas sólo se aplican a nivel de la sesión y no se combinan con la variable de entorno DD_TAGS. Por defecto: (ninguno) Ejemplo: test.code_coverage.enabled:true
--report-measures
Pares clave-valor con el formato key:123. Funciona como el parámetro --measures pero estas etiquetas sólo se aplican a nivel de la sesión y no se combinan con la variable de entorno DD_MEASURES. Por defecto: (ninguno) Ejemplo: test.code_coverage.lines_pct:82
--xpath-tag
Clave y expresión xpath con el formato key=expression que proporcionan una manera de personalizar etiquetas para tests en el archivo (el parámetro --xpath-etiquetar se puede especificar varias veces). Para obtener más detalles sobre las expresiones compatibles, consulta Proporcionar metadatos con expresiones XPath. Por defecto: (ninguno) Ejemplo: test.suite=/testcase/@classname Nota: Las etiquetas especificadas utilizando --xpath-tag y con etiquetas o variables de entorno DD_TAGS se combinan. Las etiquetas XPath tienen la mayor prioridad, ya que el valor suele ser diferente para cada test.
--logs
Permite reenviar el contenido de los informes XML como logs. El contenido dentro de <system-out>, <system-err> y <failure> se recopila como logs. Los logs de elementos dentro de un <testcase> se conectan automáticamente al test. ** Variable de entorno**: DD_CIVISIBILITY_LOGS_ENABLED Por defecto: false Nota: Los logs se facturan por separado de CI Visibility.
--max-concurrency
El número de cargas concurrentes a la API. Por defecto: 20
--dry-run
Ejecuta el comando sin cargar el archivo a Datadog. Todos los demás checks checks se realizan. Por defecto: false
--skip-git-metadata-upload
Marca booleana utilizada para omitir la carga de metadatos git. Por defecto: false
--git-repository-url
La URL del repositorio del que obtener metadatos git. Si no se pasa, la URL se obtiene del repositorio git local. Por defecto: Repositorio git local Ejemplo: git@github.com:DataDog/documentation.git
--verbose
Marca utilizada para añadir una gran cantidad de información adicional al resultado del comando **Por defecto false
Argumentos posicionales
Las rutas de archivos o directorios en los que se encuentran los informes XML de JUnit. Si pasas un directorio, la CLI busca todos los archivos .xml en él.
Además, configura el sitio Datadog para utilizar el sitio () seleccionado:
DATADOG_SITE (Obligatorio)
El sitio Datadog al que cargar los resultados. Por defecto: datadoghq.com Sitio seleccionado:
Recopilación de metadatos Git
Datadog uses Git information for visualizing your test results and grouping them by repository, branch, and commit. Git metadata is automatically collected by the test instrumentation from CI provider environment variables and the local .git folder in the project path, if available.
If you are running tests in non-supported CI providers or with no .git folder, you can set the Git information manually using environment variables. These environment variables take precedence over any auto-detected information. Set the following environment variables to provide Git information:
DD_GIT_REPOSITORY_URL
URL of the repository where the code is stored. Both HTTP and SSH URLs are supported. Example: git@github.com:MyCompany/MyApp.git, https://github.com/MyCompany/MyApp.git
DD_GIT_BRANCH
Git branch being tested. Leave empty if providing tag information instead. Example: develop
DD_GIT_TAG
Git tag being tested (if applicable). Leave empty if providing branch information instead. Example: 1.0.1
DD_GIT_COMMIT_SHA
Full commit hash. Example: a18ebf361cc831f5535e58ec4fae04ffd98d8152
DD_GIT_COMMIT_MESSAGE
Commit message. Example: Set release number
DD_GIT_COMMIT_AUTHOR_NAME
Commit author name. Example: John Smith
DD_GIT_COMMIT_AUTHOR_EMAIL
Commit author email. Example: john@example.com
DD_GIT_COMMIT_AUTHOR_DATE
Commit author date in ISO 8601 format. Example: 2021-03-12T16:00:28Z
DD_GIT_COMMIT_COMMITTER_NAME
Commit committer name. Example: Jane Smith
DD_GIT_COMMIT_COMMITTER_EMAIL
Commit committer email. Example: jane@example.com
DD_GIT_COMMIT_COMMITTER_DATE
Commit committer date in ISO 8601 format. Example: 2021-03-12T16:00:28Z
Recopilación de metadatos de configuración de entornos
Datadog utiliza etiquetas especial exclusivas para identificar la configuración del entorno en el que se ejecutan los tests, incluyendo el sistema operativo, el tiempo de ejecución y la información del dispositivo, si corresponde. Cuando el mismo test para el mismo envío se ejecuta en más de una configuración (por ejemplo, en Windows y en Linux), las etiquetas se utilizan para diferenciar el test en la detección de fallos e irregularidades.
Puedes especificar estas etiquetas especiales utilizando el parámetro --tags al llamar a datadog-ci junit upload o configurando la variable de entorno DD_TAGS.
Todas estas etiquetas son opcionales y sólo aquellas que especifiques se utilizarán para diferenciar configuraciones de entornos.
test.bundle
Se utiliza para ejecutar grupos de conjuntos de tests por separado.
Ejemplos: ApplicationUITests, ModelTests
os.platform
Nombre del sistema operativo. Ejemplos: windows, linux, darwin
os.version
Versión del sistema operativo. Ejemplos: 10.15.4, 14.3.2, 95
os.architecture
Arquitectura del sistema operativo. Ejemplos: x64, x86, arm64
runtime.name
Nombre del intérprete del lenguaje o del tiempo de ejecución de la programación. Ejemplos: .NET, .NET Core, OpenJDK Runtime Environment, Java(TM) SE Runtime Environment, CPython
runtime.version
Versión del tiempo de ejecución. Ejemplos: 5.0.0, 3.1.7
runtime.vendor
Nombre del proveedor del tiempo de ejecución, si corresponde. Por ejemplo, cuando se utiliza un tiempo de ejecución Java. Ejemplos: AdoptOpenJDK, Oracle Corporation
runtime.architecture
Arquitectura del tiempo de ejecución. Ejemplos: x64, x86, arm64
Para aplicaciones móviles (Swift, Android):
device.model
El modelo del dispositivo al que se realizan tests. Ejemplos: iPhone11,4, AppleTV5,3
device.name
El nombre del dispositivo al que se realizan tests. Ejemplos: iPhone 12 Pro Simulator, iPhone 13 (QA team)
Añadir propietarios de código
Para añadir información sobre codeowners a tus tests XML de JUnit, puedes utilizar la integración GitHub para leer el archivo CODEOWNERS en tu repositorio o proporcionar información adicional manualmente.
Como resultado, los tests XML de JUnit tienen una etiqueta test.codeowners con el propietario de dichos tests.
Uso de la integración GitHub (recomendado)
Para añadir automáticamente la etiqueta test.codeowners a tus tests, necesitas:
Proporciona el archivo de origen de los tests en tu informe XML de JUnit. Los siguientes complementos lo hacen automáticamente y añaden el atributo file a los elementos <testcase> o <testsuite> del informe XML:
phpunit
La mayoría de los complementos de Python (pytest, unittest)
La mayoría de los complementos de Ruby (minitest Ruby)
Habilita la aplicación de GitHub. Si no tienes una aplicación de GitHub, sigue los pasos de la siguiente sección. Si ya tienes
una aplicación de GitHub, habilita el permiso Contents: Read para que Datadog pueda leer el archivo CODEOWNERS. Una vez habilitado, espera unos minutos a que los cambios surtan efecto.
Nota: Github es el único proveedor Git compatible.
Configuración de una aplicación de GitHub
El XML de JUnit utiliza una aplicación de GitHub privada para leer el archivo CODEOWNERS.
Haz clic en Link GitHub Account (Vincular cuenta de GitHub).
Sigue las instrucciones para configurar la integración para una cuenta personal o de organización.
En Edit Permissions (Editar permisos), conceda acceso a Contents: Read.
Haz clic en Create App in GitHub (Crear aplicación en GitHub) para finalizar el proceso de creación de la aplicación en GitHub.
Da un nombre a la aplicación, por ejemplo, Datadog CI Visibility.
Haz clic en Install GitHub App (Instalar aplicación de GitHub) y sigue las instrucciones de GitHub.
Proporcionar manualmente la etiqueta test.source.file
Esta es una alternativa al uso de la integración GitHub.
En el caso de complementos que no proporcionan el atributo file en el informe XML, puedes proporcionar la etiqueta test.source.file.
No es necesario proporcionar la ruta exacta a un archivo específico, puedes utilizar cualquier sintaxis que utilizarías en el archivo CODEOWNERS
como src/myTeamFolder o *.md.
Existen varias formas de proporcionar la etiqueta test.source.file:
Esto añade la etiqueta test.source.file a todos los tests del informe. Todos los tests tendrán el mismo propietario.
Si quieres proporcionar diferentes archivos de origen para el mismo informe XML, puedes utilizar elementos de propiedad o definir manualmente el atributo file en elementos individuales <testcase> o <testsuite>.
Proporcionar metadatos con expresiones XPath
Además del parámetro de CLI --tags y de la variable de entorno DD_TAGS, que aplican etiquetas personalizadas globalmente a todos los tests incluidos en el informe XML cargado, el parámetro –xpath-tag` proporciona reglas personalizadas para añadir etiquetas de diferentes atributos del XML a cada test.
El parámetro proporcionado debe tener el formato key=expression, donde key es el nombre de la etiqueta personalizada que se va a añadir y expression es una expresión XPath válida dentro de las admitidas.
Aunque la sintaxis XPath se utiliza por familiaridad, sólo se admiten las siguientes expresiones:
/testcase/@attribute-name
El atributo XML de <testcase attribute-name="value">.
/testcase/../@attribute-name
El atributo XML del <testsuite attribute-name="value"> principal del <testcase> actual.
/testcase/..//property[@name='property-name']
El atributo value del <property name="property-name" value="value"> dentro del <testsuite> principal del <testcase> actual.
/testcase//property[@name='property-name']
El atributo value del <property name="property-name" value="value"> dentro del <testcase> actual.
Ejemplos:
Por defecto, la etiqueta test.suite de los tests se lee de <testsuite name="suite name">. Sin embargo, algunos complementos podrían informar de un mejor valor en <testcase classname="TestSuite">.
Para cambiar las etiquetas test.suite de value 1, value 2 a SomeTestSuiteClass, OtherTestSuiteClass:
Nota: El nombre debe ir entre comillas. Bash requiere que las comillas se escapen utilizando una barra invertida. Por ejemplo, [@name='prop'] debe introducirse como `[@name='prop'].
Cuando utilices bash desde Git para Windows, define la variable de entorno MSYS_NO_PATHCONV=1.
De lo contrario, cualquier argumento que empiece por / se expandirá a una ruta Windows.
Proporcionar metadatos mediante elementos de propiedad
Otra forma de proporcionar etiquetas adicionales a tests específicas es incluir elementos <property name="dd_tags[key]" value="value"> dentro de los elementos <testsuite> o <testcase>. Si añades estas etiquetas a un elemento <testcase>, se almacenan en su tramo de test. Si añades etiquetas a un elemento <testsuite>, se almacenan en todos los tramos de tests de ese conjunto.
Para ser procesado, el atributo name en el elemento <property> debe tener el formato dd_tags[key], donde key es el nombre de la etiqueta personalizada que se va a añadir. Las demás propiedades se ignoran.
Ejemplo: Añadir etiquetas a un elemento <testcase>.
Los valores que envías a Datadog son cadenas, por lo que las facetas se muestran en orden lexicográfico. Para enviar números enteros en lugar de cadenas, utiliza la marca --measures y la variable de entorno DD_MEASURES.
Informar de la cobertura del código
Es posible informar de la cobertura del código para un informe JUnit a través de la opción --report-measures configurando la medida test.code_coverage.lines_pct`:
