Feature request: Console with colors but no other rich output

[grv87]

Expected Behavior

I'm using Gradle under Jenkins with AnsiColor plugin.
This plugin is able to parse ANSI escapes and color console output in HTML. Other rich features such as status bar and WIP, of course, don't work.
So, to produce nice colored log without clutter in this environment Gradle should be able (i.e. have command-line option) to turn on colors only and not other rich features.

Current Behavior

Current version offers all-or-nothing only.

Either I have rich output with colors and repetitions like

<============-> 96% EXECUTING [37s]> :signProjectPluginPluginMarkerMavenPublication> IDLE<============-> 96% EXECUTING [37s]> :signProjectPluginPluginMarkerMavenPublication<============-> 96% EXECUTING [37s]> :signProjectPluginPluginMarkerMavenPublication<============-> 96% EXECUTING [37s]> :signProjectPluginPluginMarkerMavenPublication<============-> 96% EXECUTING [38s]> :signProjectPluginPluginMarkerMavenPublication<============-> 96% EXECUTING [38s]>

or I have no repetitions but no colors too.

[marcphilipp]

Which type of console output are you using? verbose?

[grv87]

I tried both verbose and rich, no visible difference.

Some update: bold font is supported by AnsiColor too.

[SpicyLemon]

I'm also interested in this.
I use gitlab for CI/CD stuff and it can handle color in the logs just fine. I currently have it using the default --console=auto. Since it's not an interactive environment, that ends up being the same as plain. If I add --console=rich then I get colors, but I also get lots of copies of the progress bars which makes the logs more difficult to read than the plain version.
It'd be nice if there were either a console option like plain-with-color, or maybe another flag/parameter like --allow-color-output[=true|false].

[adammurdoch]

I would look at solving this via #11265, rather than adding more flags. I'd also investigate what TERM environment variable these CI servers advertise and use this to selectively disable the progress logging while keeping the color output.

[SpicyLemon]

I can only really speak to GitLab here, and even then, only to how we use it at work. But the environment that runs the jobs is supplied and defined by us. So I doubt there's going to be any standard TERM values to look for. That being said, the term that our runners use (or at least the one I looked at), is dumb.

The reason I kind of like adding the flag for this, though, is that it would give me the control to dictate behavior rather than having to try to jump through hoops to trick any automatic things into doing what I want. Additionally, at least for my use case, the commands come from a script, so it's not a flag that someone needs to type in every single time they do something.

If adding a whole new --allow-color-output flag is out of the question, then I would at least want a new plain-with-color option for the --console value. The auto functionality could then be enhanced to decide between plain plain-with-color and rich, but it'd still be possible for someone to dictate which one they want when the auto detection isn't doing what they want. Honestly, I like the plain-with-color direction better, but I know it'd be more work that just adding a new flag to control it (because of the auto stuff).

[tknerr]

bumping this -- having colored output on CI builds would be really helpful indeed.

[dylanpiergies]

Yes, what we actually need is a mode that produces styled text but still produces line-oriented output, i.e. doesn't try to move the cursor around to maintain progress bars, etc.

[QazerLab]

Joining the request and asking for the colored line-oriented output too.

[kevinthecity]

Piling on, this would be super helpful for our team. Testing using rich logs on CI, but the extra noise is almost a non-starter unfortunately.

[tedgonzalez]

+1

[pshakhov]

We also need this feature too - progress bar for tasks is most annoying, for projects with many subprojects output is very messy.

[liutikas]

Any more thoughts on this? We'd like to see this as well.

[octylFractal]

I think it would be nice to support, esp. with an option such as --color=(never,auto,always) and NO_COLOR support. See https://clig.dev/#output for some details on output guidelines.

[remal]

Are there any plans regarding the issue?

[octylFractal]

Not currently.

[mustafaakin]

It'd be lovely to have this feature. Maven also has this and we use it as following in our pipelines: mvn verify --batch-mode -Dstyle.color=always --no-transfer-progress

[gwitsch]

+1 for the feature

[Toh3mi]

+1 for the feature

[KChernenko]

+1 for the feature

[xenomachina]

I would look at solving this via #11265, rather than adding more flags.

That issue is closed due to inactivity.

That said, I have to say I disagree. Magic behavior is great only when it works 100% of the time, but otherwise there needs to be a way to bypass it when it doesn't work. This is especially true in non-interactive environments like CI where reliability and repeatability are far more important than a short command-line.

The --console option works well in this respect: it defaults to "auto" which does the right thing most of the time, but when it doesn't, you can force the selection (of the available options).

The problem with --console is that it conflates verbosity, whether color is desired, and whether cursor movements (eg: for progress bars) are desired:

• plain: less verbose, no color, no cursor movement
• rich: less verbose, with color, with cursor movement
• verbose: more verbose, with color, with cursor movement

For CI environments, it would be ideal to have one or both of these combinations:

• less verbose, with color, no cursor movement
• more verbose, with color, no cursor movement

Three ideas for improving upon the status quo:

1. Two more --console choices

   Most straightforward is to just add one or both of the above combinations as additional choices for --console. eg: (names are placeholders)

   --console=auto|plain|rich|verbose|no-progress-rich|no-progress-verbose
   

   However, if it later on turns out that some users want progress bars but no color, it results in a combinatorial explosion of options. This option feels like a bit of a band-aid.

2. Two new, separate command line options

   An alternative would be to add two additional command line options. For example (again, names are placeholders):

   • one to disable color (--no-color)
   • one to disable cursor movement (--no-progress)

   This would enable combinations like:

   • --console=rich --no-progress: less verbose, with color, no cursor movement
   • --console=verbose --no-color: more verbose, no color, cursor movement

   Then --console=plain becomes a shorthand for --console=rich --no-color --no-progress. --console=auto would automatically choose verbosity, color, and cursor movement, but the other options could be used to override this. eg:

   The existing --console option would then work as it does now, though perhaps --console=auto could have new heuristics for turning off cursor movement.

3. Deprecate --console, introduce three separate options

   Maybe it would be best to scrap the --console option and start over with three separate options: (again, names are placeholders)

   • --verbose/--no-verbose
   • --color/--no-color
   • --progress-bars/--no-progress-bars

   While this is the least backward compatible, the choices for --console are already confusingly named. For example, the fact that the way one makes --console=verbose less verbose is to instead use --console=rich is more than a little weird.

   I'm not sure where the equivalent of --console=auto would fit into this, however. Maybe a fourth option? Or maybe --console isn't completely scrapped, but all of its choices other than auto are just shortcuts for setting these three options?

I'd also investigate what TERM environment variable these CI servers advertise and use this to selectively disable the progress logging while keeping the color output.

As others have mentioned, there is no real consistency here. In GitLab, CI jobs are run in a container, using whatever image has been configured for that specific job. The value of TERM can depend on the CI runner, the job's container image, and the job definition itself. There is no pre-set value that indicates that color is possible but cursor movement is not.

It's unclear how correlated "being able to determine console width" is to the need for line-based output, but if there is a correlation, then --console=auto's behavior could change to take that into account, but I repeat: in CI environments reliability and repeatability are far more important than a short command-line.

---

(If you're wondering why I spent so much time writing such a long comment, it's because I've spent far more time scanning through --console=plain output in CI logs, wondering why Gradle won't let me color code the errors so they'd stand out.)

[chrisg123]

Yea @xenomachina I agree with you. I am building in Emacs compilation mode and experiencing the same problem @grv87 described when using --console=verbose. The choice of rich/verbose and plain is insufficient. I want colorized output without any use of carriage return \r for the fancy in-place progress bar. I guess I can just use --console=plain and write a custom script to colorize the output... kind of annoying.

[alan-wint]

I ran into this problem with Spring Shell & the bootRun task. Adding --console=plain means no colors, etc, but --console=rich makes a mess of things with progress bars being re-drawn on command execution.