Logging to console and file

Help/Discuss
1

Continuing the discussion from Gradle profiler should provide summary of totals for each task by type:

I created a pull request. [Added support for total task times. by corneil · Pull Request #428 · gradle/gradle · GitHub]
Continuing the discussion from Logging to file and console:

In a Jenkins build I would never want more than lifecycle because the impact by logging debug or info level from slave is a serious performance hit and the size of the build output is far too much.
However if there is a logfile in the workspace with debug level it can be scrutinised to diagnose some problem and then be deleted before a next build or even after build is successful.

Suggestions:
Commandline options:
–logfile
–loglevel <info|debug|error>
gradle.properties
gradle.logfile
gradle.loglevel default is info

If the logfile cannot be created an error is logged to console and logging stops but build continues
If a logback.xml is present in build directory it governs the logging to file.
If logback.xml or log4.properties can lead to problems then support a subset that only controls the appender configuration and loglevel of different categories.

2

Yes, I see the need to improve logging configuration possibilities, too. Perhaps it would be cool to have a kind of dsl to configure logging like

logging {
file (‘build.log’, LogLevel.DEBUG)
console (LogLevel.INFO)
}

or to configure this in the gradle.properties.

This should be configured for all logimplementations that can be handled with slf4j. Even gradle and the plugin should use the same mechanism.

Best regards
Markus

1 Like
3

I am not sure if it should be possible to configure any kind of logging backend.

I think a gradle user may be interested in something similar to your DSL proposal:

  1. Provide for separate log level to a named file and console.
  2. Provide for configuring log level for projects and/or tasks by name to different files.

Plugin developers may be interested in provided logging configuration under SLF4J to assist with tracking down any issues by doing fine grained changes to log specific categories to files etc.

4

Yes, of course, you have to differ needs of real users and developers of the plugins to get different informations. We want the ordinary user of the build system to get less information he needs to successfully finish the build. This is in general only the progress or any errors, which occurred during the build.

If an error occurs you need a possibility to understand what’s going on under the hood if you are the developer of the plugin and maybe you faced a bug. Because the following up builds don’t work on the same environment necessarily (the build itself created some artefacts, which are not built anymore due to they are up to date), it would be important to get these informations in the build where they occur. Therefore logging into a file would be importan to have a possibility for kind of “post mortem analysis”.

The second point you have written, we have implemented for some tasks (e.g. test tasks) by iterating the tasks and setting the system property of the configuration to be used (e.g. log4j.configfile). This works for us.

5

I know this is an old thread but I still find it useful since I have been looking for this for quite while without any success.

Are there some easy ways to tee the gradle output to a logfile without redirecting it from the outside?

4 Likes
6

Did we get a solution for this in any gradle version? Is there an inbuilt gradle way yet to log the “gradlew someTask” output to a file?

7

Hi,
afaik there is no inbuilt solution so far. We have moved our generators to an own javaexec - jvm, so we can configure our logging the way we like and performance of calling a seperate vm is ok as long as having the up-to-date detection in the gradle vm itself
Cheers
Markus