2008-12-22 7 views
11

Los proyectos de My Hudson no parecen agregar adecuadamente los resultados de las pruebas posteriores y me pregunto si me he perdido un paso de configuración en alguna parte. Tengo dos proyectos, Foo y Foo-Tests, ambos son trabajos de estilo libre.Problemas con los "resultados agregados de las pruebas posteriores" en Hudson

En Foo proyecto que tengo la siguiente configuración:

  • marcó "resultados de las pruebas de agregación aguas abajo".
  • Revisado "Agrupar automáticamente todas las pruebas posteriores" en la opción anterior.
  • Marque "Crear otros proyectos" y especifique "Foo-Tests" para compilar.

El proyecto Foo-Tests tengo la siguiente configuración:

  • cuadros "Publicar resultado de la prueba JUnit informe" y se especifica mis archivos XML informe JUnit.

Cuando Foo construye, se genera correctamente y desencadena correctamente una compilación de Foo-Tests. La compilación Foo-Tests es exitosa y publica los informes JUnit correctamente. Sin embargo, cuando busco los resultados de prueba agregados en Foo, hay un enlace "Último resultado de prueba (sin pruebas)" para la compilación que me envía a un 404.

Esto es lo que he intentado que no resuelve el problema:

  • Dile a Foo que "Publique el informe de resultados de la prueba JUnit" sin parámetros (no hay pruebas en el proyecto Foo, solo Foo-Tests). Esto causó un error ya que no había archivos de prueba para procesar dentro del proyecto.
  • Dile a Foo-Tests que "huella digital de todos los artefactos publicados" sin parámetros (me preguntaba si Hudson trató los informes de JUnit como artefactos detrás de escena). Esto causó un error ya que no había definido explícitamente ningún artefacto para publicar.

Estoy usando Hudson 1.266.

Editar: Debo señalar que he encontrado dos preguntas sobre los usuarios Hudson lista de correo que no tienen respuestas y que, posiblemente, ayudar a resolver esto:

+0

También he tenido problemas para conseguir Hudson a agregarse resultados de las pruebas. Lamentablemente, la lista de correo del usuario no ha respondido al respecto. ¿Estás usando trabajos de estilo libre o maven2? –

+0

trabajos de estilo libre. También encontré dos preguntas en la lista de correo sin respuesta. Noté que uno de ellos es tuyo :). –

Respuesta

3

Pude replicar su problema con Hudson 1.266. Este es un error de Hudson, que se corrigió en una compilación posterior (anterior a 1.287), por lo tanto, actualice Hudson o use esta solución alternativa de dos clics: desde la página Proyecto, vaya primero a Última compilación y luego Agregue resultados de prueba.

El problema es que la página del Proyecto para Foo solo muestra el enlace Últimos Resultados de la Prueba, que tiene una URL como http://localhost:8080/hudson-1.266/job/Foo/lastBuild/testReport/. Como Foo no tiene pruebas propias, este enlace no tiene un archivo JUnit XML para referenciar y devuelve el error que usted mencionó. Esto se corrigió entre 1.266 y 1.287 redirigiendo desde latestBuild/testReport/back up hasta latestBuild/cuando no hay pruebas. La alternativa para usted en 1.266 es, en lugar de hacer clic en Últimos resultados de prueba en la página Proyecto, desplazarse un poco hacia abajo y hacer clic en Última compilación en Permalinks.Esto lo llevará a la última creación/URL, y desde allí puede hacer clic en Resultado de la prueba agregada, que tiene una URL como http://localhost:8080/hudson-1.266/job/Foo/lastBuild/aggregatedTestReport/. En esta página, todos los resultados de las pruebas de los proyectos posteriores estarán disponibles en la sección de profundización.

Lamentablemente, todavía hay un problema con los enlaces de profundización, incluso en 1.287. Desde Foo, cuando desgloses en Foo-Tests como se describe arriba, serás llevado a una URL mal formada, que se ve como http://localhost:8080/hudson-1.287job/Foo-Tests/. Deberá modificar manualmente esa URL para insertar un/entre el contexto hudson y la ruta de trabajo siguiente para que se vea como http://localhost:8080/hudson-1.287/job/Foo-Tests /. Entonces podrá ver los resultados de la prueba aguas abajo.

No he tenido la oportunidad de buscar en el origen de Hudson para encontrar el error, pero ya hay un problema abierto para esto. Es issue 1574, y ha estado abierto durante casi un año.

En una nota aparte, realmente me encanta Hudson para CI, pero su interfaz no es tan fluida como podría ser. Espero su retrabajo de la interfaz de usuario en ExtJS. Tal vez es en eso en lo que están pasando todo el tiempo.

+0

Gracias por la respuesta, esto es excelente. Tendré la oportunidad de probarlo mañana. –

+0

No hay problema. Volveré a comentar si encuentro la ubicación del error en la fuente. –

+0

Esto no funcionó para mí. Sin embargo, creo que esta respuesta es suficiente para la mayoría de las personas que estarían experimentando este problema. Además, la referencia a la cuestión JIRA que ya está abierta es una buena referencia externa para vigilar. Voy a marcar esto aceptado. Gracias por tu ayuda. –

2

me ha solucionado el problema que faltan '/' en Hudson 1.288

La clave para utilizar las pruebas de aguas abajo agregados resultados es ejecutar las huellas digitales en ambos puestos de trabajo. En este caso, eso sería 'Foo' y 'Foo-tests'

Hudson compara la construcción con las pruebas posteriores encontrando los archivos con las mismas huellas dactilares. Entonces esto significa que tus huellas dactilares tienen que coincidir. Algo así como una escena de crimen.

2

los dos proyectos, Foo y Foo-Test, tienen que saber que están en la misma corriente, por lo que toma las huellas dactilares (y por lo tanto el archivado) de un archivo común .

tuve que elegir un archivo que no cambió entre el funcionamiento de Foo y Foo-Test, y todavía cambia entre las dos veces que se ejecutan. para mí era un .jar no relacionado y temporal generado por Foo en el espacio de trabajo personalizado/común para mis versiones de Foo y Foo-Test.

es decir, tuve que dejar que las huellas dactilares de Foo y Foo-Test fueran del mismo archivo.

después de eso, al menos con 1.330 Hudson, las cosas funcionan - enlaces agregados, desglose, etc.

+0

Ingvald, podría aclarar, ¿tenía que ser el * mismo * archivo o un archivo con los mismos contenidos? ¿Es una buena idea dejar que Hudson use un espacio de trabajo común para esto y compartirlo entre dos trabajos? – Artem

+0

Artem, tenía que ser el mismo archivo, sí, no solo contenido idéntico. compartiendo espacio de trabajo puede ser una buena idea al principio, no menos importante ya que ahorra tiempo en la actualización de su sistema SCM (que es menos problemático cuando actualiza su sistema CI a su propia computadora, o agrega esclavos). con: relación menos directa entre compilación falla y compromisos específicos, f.ex. si desea enviar un correo electrónico al desarrollador (es) que provocó la falla de una compilación. – Ingvald

Cuestiones relacionadas