fabric-operator
fabric-operator copied to clipboard
hyperledger-labs
feat: add golangci-lint check
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/.
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.)
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.
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.