Ability to set logging level in unit tests for Gradle plugin

[szpak]

It seems to be unable to set custom logging level (by default LIFECYCLE+) for integration tests (without using TestKit) of my "business" logic (which internally uses plain SLF4J Logger) of the Gradle plugin . It makes it hard to diagnose issues with the plugin logic (e.g. connecting to external systems) running those tests.

Expected Behavior

I would like to be able to set INFO (or DEBUG) for integration tests (without Gradle being involved at all) via a logger configuration or an API call before tests execution.

Current Behavior

Only LIFECYCLE+ log statements are logged which very often is not enough.

Context

In my plugin in addition to functional tests (with nebula-test/TestKit) I have integration tests of the plugin logic. I would like to be able to change logging level to see also INFO messages (by default only LIFECYCLE+ are visible).

In my code I use standard Slf4j's Logger. First I tried with logback.xml, but Gradle seems to use its own slf4j implementation (OutputEventListenerBackedLogger) which wins in unit tests in runtime (although the code is Gradle agnostic) and I need (in a very ugly way) to get context from the logger and set in it (and in addition in OutputEventRenderer) a desired level.

Having no answer on the forum I assume it is currently not possible to achieve.

Your Environment

Gradle 3.5 (it is reproducible with any modern Gradle version).

[bmuschko]

Answered the forum post. I am not sure if there's a good solution.

[szpak]

Yup, therefore please treat is not as a question, but as a feature request. It should be possible to achieve that without working on private fields in Gradle classes.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[szpak]

It would still be valuable for people writing lower level tests (without TestKit) for business logic used in the Gradle plugin to be able to set the logging level.

[kanchanasrishti]

Hi, is there any update on this issue?

I am most probably facing the same issue.

We build and run the tests in our java application using gradle.
We program against the slf4j-interface in our application code and then plug in log4j2 framework as an implementation of that interface, which handles the actual logging.

The runtime logging on the target hardware works fine. But, JUnit tests are logged at WARN level only when running gradle test command. Changing root level logging in log4j-test.xml has no effect on the logs output from the JUnit tests.

It looks like gradle chooses to use it's own logging implementation.

Any help in this regard is highly appreciated.

Thank you in advance.

[felipebn]

Would be great to be able to do it on a straightforard way, we found a workaround to change the level by running the function below before tests:

	import org.gradle.api.logging.LogLevel
	import org.gradle.internal.logging.sink.OutputEventRenderer
	import org.gradle.internal.logging.slf4j.OutputEventListenerBackedLoggerContext
	import org.slf4j.LoggerFactory
	//...
    private fun setupGradleLogger() =
        with((LoggerFactory.getILoggerFactory() as OutputEventListenerBackedLoggerContext)) {
            level = LogLevel.DEBUG
            (outputEventListener as OutputEventRenderer).configure(LogLevel.DEBUG)
        }

This changes the logLevel in the existing Logger context.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[rnc]

This issue is still relevant