Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
deepy opened this issue Mar 4, 2021 · 5 comments

Comments

@deepy
Copy link

deepy commented Mar 4, 2021

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
Copy link
Owner

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
Copy link
Author

deepy commented Mar 4, 2021

overload a setter and have both :-)?

@deepy
Copy link
Author

deepy commented Mar 12, 2021

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
Copy link
Owner

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
Copy link
Author

deepy commented Mar 12, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants