feat: add golangci-lint check

[Abirdcfly]

This pr introduces golangci-lint to detect problems with go source code.

And turns on 4 linters: gofmt goimports govet gosimple
(The first 3 linters are maintained by golang.org, gosimple is a linter enabled by golangci-lint default)

linters	describe	link
gofmt	Gofmt checks whether code was gofmt-ed. By default this tool runs with -s option to check for code simplification	https://golang.org/cmd/gofmt/
goimports	In addition to fixing imports, goimports also formats your code in the same style as gofmt.	https://godoc.org/golang.org/x/tools/cmd/goimports
govet	Vet examines Go source code and reports suspicious constructs, such as Printf calls whose arguments do not align with the format string	https://golang.org/cmd/vet/
gosimple	Linter for Go source code that specializes in simplifying code	https://github.com/dominikh/go-tools/tree/master/simple

See a list of supported linters and which linters are enabled/disabled in https://golangci-lint.run/usage/linters/.

[jkneubuh]

Hi @Abirdcfly -

Thank you for the addition of the code simplification tools. Unfortunately, golangci-lint package has been released under a GPL license, and is incompatible with the operator's Apache license requirement.

The golang.org linters are OK to enable. Can we aim for extensions to the CI pipeline that focus on improvements to the golang linters, and make incremental updates to the areas of code that can be simplified? (I do prefer many of the suggestions made by the gosimple linter - the code changes look pretty good.)

[Abirdcfly]

golangci-lint package has been released under a GPL license, and is incompatible with the operator's Apache license requirement.

Thank you very much for pointing out the license problem, to be honest, I'm not very clear about it, the reason why golangci-lint is used is because this tool is widely used by kubernetes(Apache License 2.0) and other projects in the kubernetes ecosystem.

Through some small research, I found that there are also many other Apache License 2.0 projects using golangci-lint tool directly, for example:

• cloudflare/pint (Apache License 2.0) use in here
• kubernetes/ingress-gce (Apache License 2.0) Their golangci configuration file is available here
• aws/karpenter (Apache License 2.0) Their golangci configuration file is available here
• IBM/ibm-spectrum-scale-csi (Apache License 2.0) Their golangci configuration file is available here

There are other projects that use golangci-lint-action (MIT License) Just like this pr does:

• nginxinc/kubernetes-ingress (Apache License 2.0) Their golangci configuration file is available here
• GoogleCloudPlatform/cloud-sql-proxy (Apache License 2.0) Their golangci configuration file is available here

Some libraries we depend on also use golangci-lint:

• operator-framework/operator-lib, we used in here is Apache License 2.0 also use golangci-lint action in ci
• docker/docker, we used in here is Apache License 2.0 also use golangci-lint in test
• prometheus/client_golang, we used in here is Apache License 2.0 also use golangci-lint action in workflows

Some projects in hyperledger-labs is Apache License 2.0, also use golangci-lint action:

• hyperledger-labs/fabric-builder-k8s use golangci-lint action in here
• hyperledger-labs/perun-cosmwasm-backend use golangci-lint action in here
• hyperledger-labs/cckit use golangci-lint action in here
• hyperledger-labs/perun-eth-backend use golangci-lint action in here
• hyperledger-labs/go-perun use golangci-lint action in here

I investigated this issue because I also have a project that is Apache License 2.0 but uses golangci-lint to check the source code, and from the results above, this seems to be possible and widespread.

[jkneubuh]

We may be OK to run a GPL code linter during the build pipeline, provided that the GPL libraries are not linked in to the binaries, runtime, libraries, or docker image generated by the build.