You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use Serilog directly in a number of systems, and indirectly via some Nuke build scripts -- Nuke uses Serilog itself.
We enjoy colored console logging when running interactively, but this same code is often run in Automated Builds (TeamCity, GitHub actions, etc) where stdout is captured by the build system - sometimes indirectly through docker run or docker compose.
This leads to messy log files full of escape sequences such as this:
I am aware that this package supportsConsoleTheme.None to disable colorization, but we do not want to alter our code (or in the case of Nuke, cannot directly alter it), as then we would lose the nice coloring when running interactively on developer systems.
There are also important accessibility and compatibility reasons that people want to disable color. Colorblindness, or colors that conflict with terminal themes, etc.
The NO_COLOR=1 environment variable has emerged as a de-facto standard for this, and is supported by a wide range of software. More information at https://no-color.org/
To report a bug or request a feature, please give us as much information as possible, for example:
the exact package id and version you're using, Serilog.Sinks.Console 5.0.1 - latest on Nuget.org at time of writing Serilog.3.1.1 - latest on Nuget.org at time of writing
your dotnet toolchain version, target framework, and operating system,
` dotnet SDK 8.0.101, target framework net8.0, Windows 11
the current behavior, and
Build and run this small C# sample application.
usingSerilog;varlog=newLoggerConfiguration().WriteTo.Console().CreateLogger();log.Information("Hello, {Name}!",Environment.UserName);log.Warning("Today is {Today} and the number of the day is {Number}",DateTime.Now,12);
what you expect or want to happen instead.
When executed with the NO_COLOR env var set to 1, I expect to see no colors printed.
But: I see colorized output
Thanks!
The text was updated successfully, but these errors were encountered:
I would suggest that it should override even an explicitly set theme. A setting in code tends to be product/team wide whereas an environment variable tends to be scoped to the machine/container. More specific wins over less specific, if that makes sense. Thanks!
Sounds good to me, should be fairly straightforward to implement directly in the WriteTo.Console method, by switching the theme when the variable is detected.
Anyone following along keen to take a shot at a PR?
We use Serilog directly in a number of systems, and indirectly via some Nuke build scripts -- Nuke uses Serilog itself.
We enjoy colored console logging when running interactively, but this same code is often run in Automated Builds (TeamCity, GitHub actions, etc) where stdout is captured by the build system - sometimes indirectly through
docker run
ordocker compose
.This leads to messy log files full of escape sequences such as this:
I am aware that this package supports
ConsoleTheme.None
to disable colorization, but we do not want to alter our code (or in the case of Nuke, cannot directly alter it), as then we would lose the nice coloring when running interactively on developer systems.There are also important accessibility and compatibility reasons that people want to disable color. Colorblindness, or colors that conflict with terminal themes, etc.
The
NO_COLOR=1
environment variable has emerged as a de-facto standard for this, and is supported by a wide range of software. More information at https://no-color.org/Build and run this small C# sample application.
When executed with the NO_COLOR env var set to 1, I expect to see no colors printed.
But: I see colorized output
Thanks!
The text was updated successfully, but these errors were encountered: