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

disable the congrats message #112

Merged
merged 1 commit into from
Jun 16, 2018
Merged

disable the congrats message #112

merged 1 commit into from
Jun 16, 2018

Conversation

dahankzter
Copy link
Contributor

There is now an extra switch '-s' to disable the congrats message when
there are no issues detected

Fixes: #110

@mmatczuk
Copy link

How about making it default behaviour?

@dahankzter
Copy link
Contributor Author

That would change the current behavior and potentially break someone who for example greps for the congrats message.

@@ -84,6 +84,7 @@ func (e *Executor) needVersionOption() bool {

func initRootFlagSet(fs *pflag.FlagSet, cfg *config.Config, needVersionOption bool) {
fs.BoolVarP(&cfg.Run.IsVerbose, "verbose", "v", false, wh("verbose output"))
fs.BoolVarP(&cfg.Run.DisableCongrats, "no-congrats", "s", false, wh("disable congrats output"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. maybe silent instead of no-congrats and Silent instead of DisableCongrats? It will be more general logic. Also in some places options disables not only congrats message, e.g. in JSON
  2. s/disable/Disable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure it makes sense.

allIssues := []result.Issue{}
for i := range issues {
allIssues = append(allIssues, i)
}

if len(allIssues) == 0 && j.disableCongrats {
return true, nil
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's ugly and we need to refactor it. Here need to return false: it's a flag that issues were found

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok I missed the logic a bit here

@@ -8,22 +8,30 @@ import (
"github.com/golangci/golangci-lint/pkg/result"
)

type JSON struct{}
type JSON struct {
disableCongrats bool
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JSON knows nothing about congrats, silent or more specific for JSON like omitEmpty

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My vote is for silent here as well I think.

@jirfag
Copy link
Member

jirfag commented Jun 16, 2018

thank you for the pull request!

@dahankzter
Copy link
Contributor Author

I will make the suggested changes asap.

@dahankzter dahankzter force-pushed the master branch 2 times, most recently from 30e525f to a7d29b8 Compare June 16, 2018 09:18
allIssues := []result.Issue{}
for i := range issues {
allIssues = append(allIssues, i)
}

if len(allIssues) == 0 && j.silent {
return false, nil
Copy link

@arp242 arp242 Jun 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned here, I'm not sure this is actually useful to do for JSON output. It's off by default so not a huge deal as such, but the "silent" flag is pretty generically named and could also change other behaviour in the future, and having it output invalid JSON as a kind of side-effect may surprise people.

It may also be confusing in some cases where users provide custom flags to the editor integration or some such, and the editor isn't prepared to deal with invalid JSON, causing confusing errors.

Personally I think always outputting valid JSON is much better, and would simplify the life of people implementing this in editors (i.e. me 😄).

Copy link
Member

@jirfag jirfag Jun 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree about valid JSON, it would be better to not change JSON output at all. And checkstyle too, hide only congrats message for text and tab printers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure for JSON we can just emit {} perhaps or simply let it be as it was. @mmatczuk has a point though to consider.

What about the checkstyle xml? Perhaps it should also produce valid xml?

Tab and text can be silenced then is this the temporary consensus until a major decision is made as to the default behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I just now saw you mentioned checkstyle as well @jirfag

@mmatczuk
Copy link

mmatczuk commented Jun 16, 2018

@Carpetsmoker I agree that JSON should not be silenced, my point was that maybe it could be just {} but it's a knob...

@jirfag I'm not sure if adding the silent flag is a move in right direction

  1. it does not really solve the Rule of Silence - by default say nothing
  2. another flag adds complexity to the tool
  3. it's not really clear how silent relates to verbose flag
  4. I do not see a lot of possibilities to reuse the silent flag for other things

Please reconsider, thanks.

There is now an extra switch '-s' to disable the congrats message when
there are no issues detected

Fixes: golangci#110
@dahankzter
Copy link
Contributor Author

The Checkstyle and JSON output is back to where it was now.

@jirfag jirfag merged commit f239b80 into golangci:master Jun 16, 2018
@jirfag
Copy link
Member

jirfag commented Jun 16, 2018

thank you!

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

Successfully merging this pull request may close these issues.

Suppress congrats message
5 participants