Color coding in log output is enabled by default; Please disable by default. #8811

New Issue

GiteaMirror · 2025-11-02T08:19:38-06:00

GiteaMirror commented

2025-11-02 08:19:38 -06:00

Originally created by @cmpunches on GitHub (Apr 10, 2022).

Description

Example:

Apr 10 22:24:32 source gitea[1705186]: #033[36m2022/04/10 22:24:32 #033[0mStarted #033[34mGET#033[0m #033[1m/SURRO-Linux/Rex/commits/commit/f4a38de0c07d6aead324918325064a3dd3b19a3d/src/loaders#033[0m for #033[1m51.222.253.4:0#033[0m

I see in the documentation someone thinks that "Further, on *nix it is becoming common to have file logs that are colored by default. Therefore file logs will be colorised by default when not running on Windows" ( https://docs.gitea.io/en-us/logging-configuration/#log-colorization ).

I cannot stress more emphatically how this is not the case.

Any environment that does anything other than "log to local file" and has any form of log aggregation/centralization will just see this as another setting they have to mess with to turn it off in order to make their logs sanely ingestable, and while the GNOME and KDE VTEs (and VTEs based on them) have color code interpretation, alot of VTEs still don't, and in some environments VTE selection is not optional; in any case, this causes legibility issues of the entries in lieu of forcing users to change terminals until they bring in centralized logging and then they have to go digging around for settings to mess with in their gitea instance, and only their gitea instance (because none of their other services do this).

It is not the purpose of the log-generating component to beautify their output data as that's the purpose of whatever component is rendering that data to the user. The generating component should generate in such a way as to be agnostic of the rendering component.

In the spirit of clarity, in the perspective of the log-generating component, its purpose is to generate data about events in the system telling it to generate that data. Somewhere down the line, a product not controlled by gitea renders that data to the user -- whether it's cat or grep or less or kibana or one of the myriad of other browser-based rendering systems -- often at the other end of a transformation pipeline that normalizes their log entries from across all the other services in their environment. It is that latter component's function to beautify that data based on its rendering method-- whether a browser-based method, or GTK, or QT or some off-the-wall TUI library that becomes popularized that week as the future of user interfaces in obscure nodejs circles.

I mean, if someone is doing unique things with their logging and wants color codes in their logs, I'm not one to stand in their way, but they are the exception and not the norm-- Let their log rendering system add color codes if somebody wants to beautify their logs. Or, at the very best, they could write a rules engine in their log transformations to add them in if they want.

That all starts with log normalization, which color codes impede.

Gitea Version

1.15.6

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

embedded in bug report

Screenshots

N/A

Git Version

It's still 1.15.6

Operating System

CentOS 8

How are you running Gitea?

self-hosted

Database

MySQL

Originally created by @cmpunches on GitHub (Apr 10, 2022). ### Description Example: ``` Apr 10 22:24:32 source gitea[1705186]: #033[36m2022/04/10 22:24:32 #033[0mStarted #033[34mGET#033[0m #033[1m/SURRO-Linux/Rex/commits/commit/f4a38de0c07d6aead324918325064a3dd3b19a3d/src/loaders#033[0m for #033[1m51.222.253.4:0#033[0m ``` I see in the documentation someone thinks that _"Further, on *nix it is becoming common to have file logs that are colored by default. Therefore file logs will be colorised by default when not running on Windows"_ ( https://docs.gitea.io/en-us/logging-configuration/#log-colorization ). I cannot stress more emphatically how this is **not** the case. Any environment that does anything other than "log to local file" and has any form of log aggregation/centralization will just see this as another setting they have to mess with to turn it off in order to make their logs sanely ingestable, and while the GNOME and KDE VTEs (and VTEs based on them) have color code interpretation, alot of VTEs still don't, and in some environments VTE selection is not optional; in any case, this causes legibility issues of the entries in lieu of forcing users to change terminals until they bring in centralized logging and then they have to go digging around for settings to mess with in their gitea instance, and only their gitea instance (because none of their other services do this). It is not the purpose of the log-generating component to beautify their output data as that's the purpose of whatever component is rendering that data to the user. The generating component should generate in such a way as to be agnostic of the rendering component. In the spirit of clarity, in the perspective of the log-generating component, its purpose is to generate data about events in the system telling it to generate that data. Somewhere down the line, a product not controlled by gitea renders that data to the user -- whether it's `cat` or `grep` or `less` or `kibana` or one of the myriad of other browser-based rendering systems -- often at the other end of a transformation pipeline that normalizes their log entries from across all the other services in their environment. It is that latter component's function to beautify that data based on its rendering method-- whether a browser-based method, or GTK, or QT or some off-the-wall TUI library that becomes popularized that week as the future of user interfaces in obscure nodejs circles. I mean, if someone is doing unique things with their logging and wants color codes in their logs, I'm not one to stand in their way, but they are the exception and not the norm-- Let their log **rendering** system add color codes if somebody wants to beautify their logs. Or, at the very best, they could write a rules engine in their log transformations to add them in if they want. That all starts with log normalization, which color codes impede. ### Gitea Version 1.15.6 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist embedded in bug report ### Screenshots N/A ### Git Version It's still 1.15.6 ### Operating System CentOS 8 ### How are you running Gitea? self-hosted ### Database MySQL

GiteaMirror added the type/question label 2025-11-02 08:19:38 -06:00

GiteaMirror closed this issue

2025-11-02 08:19:38 -06:00

GiteaMirror commented

2025-11-02 08:19:39 -06:00

@silverwind commented on GitHub (Apr 11, 2022):

There various methods through which a program can detect whether to output color. Generally, if the connected output stream is not a TTY (like a file), color output should only be selectively enabled based on environment heuristics.

@silverwind commented on GitHub (Apr 11, 2022): There [various methods](https://github.com/chalk/supports-color/blob/main/index.js) through which a program can detect whether to output color. Generally, if the connected output stream is not a TTY (like a file), color output should only be selectively enabled based on environment heuristics.

GiteaMirror commented

2025-11-02 08:19:39 -06:00

@cmpunches commented on GitHub (Apr 11, 2022):

Again, you don't want to give the source of the data the responsibility of rendering it. When you add color codes you are interfering with the rendering process and it's out of scope. Bear in mind that we're talking about system logs.

It is not the purpose of the log-generating component to beautify their output data as that's the purpose of whatever component is rendering that data to the user. The generating component should generate in such a way as to be agnostic of the rendering component.

@cmpunches commented on GitHub (Apr 11, 2022): Again, you don't want to give the source of the data the responsibility of rendering it. When you add color codes you are interfering with the rendering process and it's out of scope. Bear in mind that we're talking about system logs. > It is not the purpose of the log-generating component to beautify their output data as that's the purpose of whatever component is rendering that data to the user. The generating component should generate in such a way as to be agnostic of the rendering component.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8811