search

runningcode / gradle-doctor

The right prescription for your Gradle build.
http://runningcode.github.io/gradle-doctor
Apache License 2.0
736 stars 48 forks source link

warnWhenNotUsingParallelGC fails the build, warn is a confusing keyword here #152

Open deepy opened 3 years ago

deepy commented 3 years ago

Currently warnWhenNotUsingParallelGC is a check that fails the build

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'foo'.
> =============================== Gradle Doctor Prescriptions ============================================
  | For faster builds, use the parallel GC.                                                              |
  | Add -XX:+UseParallelGC to the org.gradle.jvmargs                                                     |
  ========================================================================================================

Normally when I see the word warn I'd expect a warning to be printed but the build to succeed. Looking through at extension it seems like maybe these checks could benefit from being an enum like: IGNORE, WARN, FAIL

runningcode commented 3 years ago

I like the idea of the enum. I will play with this a bit. The thing is an enum can be tricky to use with the kotlin Gradle DSL since then you'll have to import the enum. A string might be better.

deepy commented 3 years ago

overload a setter and have both :-)?

deepy commented 3 years ago

I've been thinking about messages some more and I think an additional value would be useful.

My scenario is that we've got a large team working on this but not everyone works on the build and as a result we're showing a lot of information to people who can't make good use of it. However, we'd still want to do the checks and get tagged build-scans for analysis purposes.

So something like TAG_ONLY, BACKGROUND or SILENT.

Though I guess that leaves us without a good way to make use of the report

runningcode commented 3 years ago

Very good point. What does background do? Warn only? What about erroring the build?

so tag, warn, error and off?

maybe the tagging, warning, and error messages should all be configured independently?

deepy commented 3 years ago

the way I see it: warnings should be shown but not fail the build, errors should always be shown and fail the build, anything silent should never fail the build.

tag, background, or silent is just suggestions on name, neither should fail the build or be shown