`--verbose` mode doesn't respect `--color` flag or `NO_COLOR` env

[ccoVeille]

Welcome

• Yes, I'm using a binary release within 2 latest releases. Only such installations are supported.
• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've read the typecheck section of the FAQ.
• Yes, I've tried with the standalone linter if available (e.g., gocritic, go vet, etc.).
• I agree to follow this project's Code of Conduct

How did you install golangci-lint?

Brew

Description of the problem

golangci-lint custom is supposed to support color flags

I want to be able to deactivate, but I cannot.
I feel like a flag is not parsed.

Version of golangci-lint

$ golangci-lint --version
golangci-lint has version 2.1.6 built with go1.24.2 from eabc263 on 2025-05-04T15:36:41Z

Configuration

This is a .custom-gcl.yml file

version: v2.1.6
plugins:
  - module: foo
    path: .

Go environment

$ go version && go env
# not relevant

Verbose output of running

$ golangci-lint custom --help
Build a version of golangci-lint with custom linters

Usage:
  golangci-lint custom [flags]

Global Flags:
      --color string   Use color when printing; can be 'always', 'auto', or 'never' (default "auto")
  -h, --help           Help for a command
  -v, --verbose        Verbose output

A minimal reproducible example or link to a public repository

• Create a new folder with mktemp -d
• cd to it
• Create this .custom-gcl.yml file

version: v2.1.6
plugins:
  - module: foo
    path: .

You need nothing else, no code, no plugin, just this file

$ golangci-lint custom -v --color=never

$ NO_COLOR=1 golangci-lint custom -v --color=never

The custom command fails as there is nothing it can build.

But the colors are present.

This issue also occurs when a module is fully set up

Validation

• Yes, I've included all information above (version, config, etc.).

Supporter

• I am a sponsor/backer through GitHub or OpenCollective

[ccoVeille]

Maybe I'm wrong here, because the verbose mode of golangci-lint run -v doesn't respect the color settings either

same for golangci-lint fmt -v

So here I assume, the verbose mode doesn't respect the --colors=never flag or the NO_COLOR=1 env.

I think it would be better if it was, but I wrongly assumed the issue was only with custom command.

So here, two conclusions:

• maybe there is something to do with the verbose mode so it respects the color flag/env
• maybe the custom command shouldn't have a --color flag, as it's misleading.

[ccoVeille]

OK, I dug into the code and logrus is used.

CLICOLOR=0 env can be used.

So I have a solution for my issue.

I would have expected the logger to respect --color=never flag and NOCOLOR=1 env

golangci-lint/pkg/logutils/stderr_log.go

Lines 47 to 55 in 65c85df

	formatter := &logrus.TextFormatter{
	DisableTimestamp: true, // `INFO[0007] msg` -> `INFO msg`
	EnvironmentOverrideColors: true,
	}
	if os.Getenv(envLogTimestamp) == "1" {
	formatter.DisableTimestamp = false
	formatter.FullTimestamp = true
	formatter.TimestampFormat = time.StampMilli
	}

There is a DisableColors and ForceColors fields in logrus.TextFormatter

https://pkg.go.dev/github.com/sirupsen/logrus#TextFormatter

So here, it's open to debate if it's a problem or not.

If not, the only remaining issue would be that the custom accepts --color flag, while it doesn't use colors.

So maybe, a simple "fix" could be to make custom a bit more verbose and return colored text.

[ldez]

The logger is set up before everything (the logger is required before the flag parsing), and the --color is related to "normal" logs.

So I don't consider this something to fix.

The custom command doesn't need to be more verbose: only the warn and error are logged by default, as expected.

[ldez]

Can you explain in what context this could be a problem?

[ccoVeille]

I was surprised golangci-lint custom --verbose wasn't respecting NO_COLOR or --color=never.

I noticed it because they were the only onr in color, in a script with NO_COLOR=1

So I reported as a bug, because I thought golangci-lint custom was the only one with that problem.

Now that I have looked at the code and see that the log in verbose are separate from messages reported without verbose mode.

I looked at the code, it's clear now.

I have a workaround with CLICOLOR=0

I faced this because when building module via custom command, we can see a progression and information that I find useful, such as the path used in the go mod -replace

I had an issue once because I had ../../.. instead of ../.. in path variable in my .custom-gcl.yaml

The verbose mode helped me to figure it out more easily than the go mod tidy error message

[ldez]

Can you explain what your context is where the colors could be a problem?

[ccoVeille]

A problem, no. Simply a surprise to see colors when I thought I had disabled them.

About the "why having color could be an issue", it can be when the isatty wrongly reports it's a terminal.

I saw it in Jenkins lately logs, where you see

\e[0;31mSTATUS\e[0 message

So being able to disable color with NO_COLOR or flag, avoid the strange rendering.