Print total number of issues, even if maxIssues is not reached, exit code 0 #5957
-
|
Your feature request may already be reported! Current BehaviorCurrently, if the ContextWe check the total number against the allowed number in our CI pipelines, to make sure if a new lower bound is reached that we configure out But it's not easy to do this without either running the process twice, or piping |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
|
Why don't you use a baseline instead? I have a baseline with all the current errors and set the allows errors to 0. The baseline suppresses all those known errors but doesn't allow new ones. Then I also have a nightly that regenerates that baseline. Because we don't allow to merge anything with new errors that task only removes the fixed things from the baseline to avoid regressions. |
Beta Was this translation helpful? Give feedback.
-
|
I converted this to a discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Further discussion is welcome. 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
How often does a baseline need updating? What if a function is renamed, etc. I think this should be an option, not a requirement. We should consider the pros and cons of outputting an error/warning count even when the check passes (this is how I ended up solving this a different way (which has its own limitations), by ignoring unmodified files and allowing zero issues (so either resolve or suppress any new ones). For small PRs this also dramatically speeds up the linting process. See the below DETEKT_END_FILE ?= ~/.local/lib/detekt-cli-1.22.0-all.jar
REMOTE_HEAD ?= origin/master
CHANGED_FILES_KT ?= $(shell git diff $(REMOTE_HEAD) --name-only --diff-filter=MACRU \*.kt \*.kts)
.PHONY: lint
lint: ## run Detekt on changed .kt/.kts files
# Lint any changed .kt or .kts files
if [ "$(CHANGED_FILES_KT)" ]; then \
java -jar $(DETEKT_END_FILE) --parallel --max-issues 0 -i $(shell echo $(CHANGED_FILES_KT) | tr ' ' ','); \
fi |
Beta Was this translation helpful? Give feedback.
-
|
For sure, everything could be implemented but we should focus on common scenarios. Baseline fixes your issue. Your exposed solution fixes your issue. And, if you want, you can implement your own console report and report whatever you want. |
Beta Was this translation helpful? Give feedback.
Why don't you use a baseline instead? I have a baseline with all the current errors and set the allows errors to 0. The baseline suppresses all those known errors but doesn't allow new ones.
Then I also have a nightly that regenerates that baseline. Because we don't allow to merge anything with new errors that task only removes the fixed things from the baseline to avoid regressions.