¿Cómo desactivar la salida de los ganchos de apagado en las pruebas de arranque de gradle?


13

Puede generar un proyecto desde start.spring.io a este problema desde https://start.spring.io/starter.zip?type=gradle-project&language=java&bootVersion=2.2.5.RELEASE&baseDir=demo&groupId=com.example&artifactId=demo&name = demo & description = Demo% 20project% 20for% 20Spring% 20Boot & packageName = com.example.demo & packaging = jar & javaVersion = 1.8 & dependencies = h2, data-jpa, web

Tengo una aplicación SpringBoot de varios módulos construida con gradle, hay un montón de pruebas de integración SpringBoot. Cuando hago una compilación, termino con una salida del cierre de SpringBoot a la consola como se muestra a continuación. ¿Cómo apago esta salida?

± |master 1 {1} S:3 U:10 ✗|  ./gradlew build

> Task :core:test
2020-02-01 11:20:33.529  INFO 24114 --- [extShutdownHook] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2020-02-01 11:20:33.531  INFO 24114 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown initiated...
2020-02-01 11:20:33.538  INFO 24114 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown completed.

> Task :email:test
2020-02-01 11:20:43.820  INFO 24150 --- [extShutdownHook] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2020-02-01 11:20:43.820  INFO 24150 --- [extShutdownHook] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2020-02-01 11:20:43.822  INFO 24150 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-2 - Shutdown initiated...
2020-02-01 11:20:43.822  INFO 24150 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown initiated...
2020-02-01 11:20:43.830  INFO 24150 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown completed.
2020-02-01 11:20:43.830  INFO 24150 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-2 - Shutdown completed.

> Task :security:test
2020-02-01 11:20:54.941  INFO 24188 --- [extShutdownHook] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2020-02-01 11:20:54.944  INFO 24188 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown initiated...
2020-02-01 11:20:54.952  INFO 24188 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown completed.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.1.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 46s
57 actionable tasks: 54 executed, 3 up-to-date

Como referencia, una aplicación creada desde start.spring.io con gradle no produce ningún resultado en la pantalla

./gradlew build

BUILD SUCCESSFUL in 779ms
5 actionable tasks: 5 up-to-date

En cambio, la salida se coloca en build/reports/

En mi caso, NO he realizado ningún cambio en la configuración de registro que viene con el arranque. No hay logback.xml o cambios en application.yml para los niveles de registro. Espero que Gradle esté capturando el sistema y el error del sistema y enviándolos al, build/reports/pero algunas salidas parecen estar escapando al sistema.


2
Ajustar el nivel de registro para esos paquetes o clases a continuación INFO(o eliminar por completo).
Kayaman

2
Esas son INFOlíneas de registro de nivel. Como se ve, se originan en los ganchos de apagado y terminan donde se configura el registro. Supongo que, en teoría, los mensajes podrían terminar en un lugar diferente al previsto, debido al cambio de configuración de registro y la ejecución de los ganchos de forma asincrónica después. Por lo tanto, las líneas serían predeterminadas a la consola, ya que la configuración anterior se descargó. Tal vez.
Kayaman

1
¿Puedes agregar tu clase de prueba y tu clase de aplicación principal también, por favor? ¿Y alguna application.properties/yml relevante asociada con la configuración del origen de datos?
Darren Forsythe

3
Podría ser que los enganches de apagado sucedan cuando los procesos de trabajo de prueba de Gradle se rechazan después de que su redirección de salida se desgarra. Eso podría valer un problema de gradle / gradle para abrir la discusión.
Eskatos

2
Idealmente, el arranque de primavera se apaga en sus pruebas sin tener que depender de los ganchos de apagado de jvm, eso sería un problema de primavera.
Eskatos

Respuestas:


4

@eskatos tiene razón. El administrador de registro se debilita después de ejecutar el caso de prueba antes de cerrar el proceso de trabajo. Todos los ganchos de apagado se ejecutan cuando se cierra el proceso de trabajo y se redirigen a la consola.

Como estos mensajes son generados por el arranque de primavera, el mejor lugar sería filtrar los mensajes de apagado utilizando la configuración de prueba de logback xml.

Algo como logback-test.xml dentro de src / test / resources

<configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <filter class="ch.qos.logback.core.filter.EvaluatorFilter">
            <evaluator> <!-- defaults to type ch.qos.logback.classic.boolex.JaninoEventEvaluator -->
                <expression>return event.getThreadName().contains("ShutdownHook");</expression>
            </evaluator>
            <OnMismatch>NEUTRAL</OnMismatch>
            <OnMatch>DENY</OnMatch>
        </filter>
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="STDOUT" />
    </root>
</configuration>

build.gradle

testCompile 'org.codehaus.janino:janino'

1
OMI, la mejor solución alternativa hasta ahora.
Steffen Harbich

3

Uno puede deshabilitar la salida con o decidir qué registrar de una tarea, para controlar el stdout / stderr de la JVM de prueba:TestLoggingContainer testLogging.showStandardStreams = false onOutputTest

apply plugin: 'java'

test {

    // show standard out and standard error of the test JVM on the console
    // can be used to disable the console output:
    testLogging.showStandardStreams = true

    // listen to standard out and standard error of the test JVM
    // can be used to make the logging optional:
    onOutput { descriptor, event ->
        logger.lifecycle("Test: " + descriptor + " produced standard out/err: " + event.message)
    }
}

Estas transmisiones son TestLogEvent STANDARD_OUT& STANDARD_ERROR, que provienen de la JVM. Cuando se puede determinar un event.messagecontenido extShutdownHook, se puede omitir el registro.


ver Puede generar un proyecto desde start.spring.io a este problema desde start.spring.io/… para reproducir el problema
enms.

Probablemente no sea un problema, porque INFOes el nivel de registro predeterminado para Spring; uno puede establecer otros niveles de registro, por ejemplo. logging.level.org.springframework=TRACEcomo variable ambiental.
Martin Zeitler

1
Creo que los registros de gancho de apagado se generan fuera de la tarea de prueba. ¿Podría actualizar su respuesta para mostrar cómo se pueden filtrar los mensajes de enlace de cierre? Creo que el mejor lugar para filtrar estos mensajes es donde se generan, de todos modos, en el arranque de primavera.
Sagar Veeram

3

Podría ocultar el registro de prueba específico de los datos de primavera (basado en este inicio de primavera ) agregando lo siguiente application.propertiesa src / test / resources:

logging.level.root=ERROR

logging.level.org.springframeworkno tendrá efecto, por ejemplo com.zaxxer.hikari, en el registrador, pero aquí tiene opciones flexibles .

( root=ERRORes como el "enfoque del martillo de trineo").

( src/main/resourcestambién es posible, pero tiene efecto no solo en la prueba sino también en el tiempo de ejecución de la aplicación) ( application.propertieses solo una de las muchas "ubicaciones" posibles para esta propiedad ... ver también: https://docs.spring.io/spring-boot/ docs / current / reference / html / appendix-application-properties.html )

Con esto obtengo una salida gradle "silenciosa", también en clean build:

$ ./gradlew clean build

BUILD SUCCESSFUL in 10s
7 actionable tasks: 7 executed

0

Gradle tiene un modo silencioso.

./gradlew build -q

Pero aún necesita información sobre las pruebas. puedes usar jacoco y sonarqube. Funcionó para mí aquí y aquí .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.