build-tags shouldn't have to be allowed manually one by one

[lopezator]

Current behavior:

If you have any file with a build tag, e.g. // +build integration or others, files under that tag won't be checked unless you explicitly pass them manually by using:

run:
  build-tags:
    - integration

Or the corresponding --build-tagsflag.

I've been using golangci-lint for the past few months and didn't noticed this behavior until now. I have a lot of tests against a DB marked as // +build integration and thus, weren't being checked by golangci-lint.

In addition I think it's easy to forget to modify golangci-lint config everytime you add a new tag to your code, resulting in a lot of bad formatted, unchecked files.

Proposal:

Using https://golang.org/pkg/go/parser/ or some other tool (I would have to investigate further), to discover all the build tags present on the project, extracting a list.

The proposed golangci-lint behaviour would enable by default all build tags (or at least have a new enable-all property for backwards compatibility purposes), being able to disable individual checks as you wish.

This way, you can keep a sane synced config even if you modify your code or add new tags to it without having to modify golangci-lint config every time.

What do you think @jirfag ?

[jirfag]

Hi, thank you for the proposal. I'm not sure that we can do it automatically because if we enable all build program may not compile because of e.g. conflicting function definitions. I think a tool for printing all build tags will be useful. And using this tool anyone can run golangci-lint multiple times with needed combinations of tags.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[starius]

Some linters (i.e. go fmt) can run on all the files of all tags even in case of conflicting definitions. Currently go fmt does a better job of detecting formatting issues, than golangci-lint. Let's fix this.

[lopezator]

Would you be open to take over this @starius ? Contributions are welcome :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.