Ability to set log level for specific task

[eriwen]

As a user, I would like to be able to debug just one specific task. Something like:

task myTask {
  logging.level = LogLevel.INFO

  doLast {
    logger.info("Output on INFO level")
  }  
}

Expected Behavior

Given the build file above, I'd like "Output on INFO level" to be printed if I run gradle myTask

Current Behavior

Currently, "Output on INFO level" is not logged.

Context

This was submitted by @etiennestuder in GRADLE-2658 with 5 votes.

Your Environment

• Build scan URL: https://scans.gradle.com/s/kskkhina7io2e

[NicolasRouquette]

I know that the following is based on internal APIs....
Just in case it might work, i noticed that logger in gradle 3.3 is an OutputEventListenerBackedLogger; which provides public access to a OutputEventListenerBackedLoggerContext, I tried the following in a build.gradle:

gradle.taskGraph.beforeTask { Task task ->
	if ('bintrayUpload' == task.name) {
		println "... ${task.name}: log level=${logger.context.level}"
		logger.context.level = LogLevel.INFO
		logging.captureStandardOutput LogLevel.INFO
		println "^^^ ${task.name}: capture stdout to log level=${logger.context.level}"
	} else {
		println "... ${task.name}: log level=${logger.context.level}"
	}
	
}

That did change the logging level but had no change on what is logged.

[DPUkyle]

Now that I'm trying to get remote cache working with my language plugin, the ability to switch on debug-level logging for a single task would be oh-so-helpful.

[kamalmarhubi]

Additionally, I'd find it very useful to be able to set this from the command line.

[rahtr]

Is this still an issue?

[rbuehlma]

I can confirm this issue still persists with gradle 5.5.1

[jrodguitar]

@NicolasRouquette i tried the opposite of what you did. in the command line i passed the flag --info, and i added the following code

gradle.taskGraph.beforeTask { Task task ->
	if ('bintrayUpload' != task.name) {
		println "... ${task.name}: log level=${logger.context.level}"
		logger.context.level = LogLevel.LIFECYCLE
		logging.captureStandardOutput LogLevel.LIFECYCLE
		println "^^^ ${task.name}: capture stdout to log level=${logger.context.level}"
	} else {
                logger.context.level = LogLevel.INFO
		println "... ${task.name}: log level=${logger.context.level}"
	}	
}

And that changes the log level and the output. Not exactly what we want to accomplish, but it is a bit helpful. Surprisingly it works fine when going from info to lifeCycle, but not the other way around.

[Horcrux7]

4 years, 52 votes and no progress. I ask me as plugin developer if I should ignore Gradle logging setting and do my own thing. The follow code would work:

                if( task.getLogger().isDebugEnabled() ) {
                    task.getLogger().lifecycle( "message" );
                }

[rnc]

@Horcrux7 That is exactly what we chose to do within our plugin : https://github.com/project-ncl/gradle-manipulator/blob/master/common/src/main/java/org/jboss/gm/common/logging/GMLogger.java

[mateuszkwiecinski]

Up to gradle 6.7.1 there was a workaround to use deprecated replaceLogger method

Unfortunately 6.8 removed deprecated method by replacing it with decorateLogger and than replaced with setLoggerMessageRewriter which isn't called for all messages.
I hoped this issue will be fixed by the time replaceLogger is removed :/
AFAIU the change I described had introduced regression #15747 which is related to logging, so there will be some work around it planned. It would be great if this issue could be addressed as well 🤞

And just to add another usecase to the feature request: when runing Android Tests on Android device, the related Gradle task (DeviceProviderInstrumentTestTask) doesn't notify us of any progress by default. Progress becames available only when running with --info flag, but that produces tones of useless logs from the whole build. As Android team doesn't seem to care about the feature request, we've been overriding log level to Info for DeviceProviderInstrumentTestTask task to know if tests are still executing (task execution takes around 25 minutes) or if i.e. Android emulator got stuck.

[eskatos]

@mateuszkwiecinski The replaceLogger method was both deprecated and internal, never intended for public use. I'm not saying there's a need for a public feature. That's what this issue is about.

Also see this related issue #13090

[huehnerlady]

Is there any update on this? It is a very useful feature as you get tons and tons of debug logging if you do not reduce to a task

[DenBond7]

we've been overriding log level to Info for DeviceProviderInstrumentTestTask task to know if tests are still executing

@mateuszkwiecinski could you share details on how did you do that?

[mateuszkwiecinski]

@DenBond7 - Here's my implementation: https://github.com/otwarty-wykop-mobilny/wykop-android/blob/8525b12222f0a3ab27105a96606722bc7a73c54d/buildSrc/src/main/kotlin/com/android/build/gradle/internal/LoggerWrapper.kt#L36 (I'm not sure if this still works though after all dependency updates over last year 😛 but the general idea persists - to override AGP's class with configurable logger).

[romulof]

In a failed attempt to redirect task.logger.info to task.logger.lifecycle for a specific task, I did this:

def debug = project.findProperty('debug')
if (debug) {
    def debugTasks = debug.tokenize(',')
    gradle.taskGraph.whenReady { taskGraph ->
        for (task in taskGraph.allTasks) {
            if (task.name in debugTasks) {
                logger.lifecycle("[${task.path}] Debug mode enabled")
                task.logger.metaClass.info = { String message, Object... objects ->
                    task.logger.lifecycle(message, objects)
                }
            }
        }
    }
}

Apparently Groovy metaClass does not work with Java objects.

[foxpluto]

I am interested in this feature too.

[twbecker]

This is sorely needed. Debugging an issue with a single task currently requires increasing the log verbosity of the entire (potentially large) build.

[xtermi2]

another good option would be to set a level e.g via gradle.properties like this:

org.gradle.logging.level.my.package.name.or.fqcn=INFO

or the equivalent via GRADLE_OPTS

GRADLE_OPTS="-Dorg.gradle.logging.level.my.package.name.or.fqcn=INFO"

[roded]

Gradle team, please consider giving this 8 yo issue some attention it would considerably simplify users' ability to leverage the Gradle cache.

[mjustin]

Gradle team, please consider giving this 8 yo issue some attention it would considerably simplify users' ability to leverage the Gradle cache.

It's almost 11 years old, when you consider that this issue was almost four years old when it was migrated from Jira issue (GRADLE-2658)[https://issues.gradle.org/browse/GRADLE-2658] to this current GitHub issue.

[oliveryasuna]

Would be a very useful feature.

[antonurankar-moloco]

+1