forked from rook/rook
Blaine Gardner
526acaf868
Kubernetes has begun releasing a kube-api-linter application for linting Kubernetes APIs to match against common best-practices. (a.k.a., KAL). Of note: KAL is still new and has no semver releases. I believe this linter is helpful in encouraging Rook devs to think deeply about how end-users consume the API. It ensures that new APIs account for set/unset status, zero values, upper/lower bounds, and possibly others in the future. This commit adds initial support to Rook, without making the results a requirement. Maintainers still need to evaluate rule configuration and determine how tightly Rook wants to hold to the results. As of this commit, I observe around 650 "issues" with the current Rook APIs. This doesn't mean that Rook is in danger of breaking. Issues with API types are often just indications that upper/lower bounds are missing, or that there is ambiguity between set-empty and unset-empty values. This commit uses `--new` in CI to ensure only new API issues are flagged. Also of note, KAL is a golangci-lint plugin. It is possible to locally build KAL (from source) into golangci-lint to run both at the same time. However, this is time-consuming, and it's harder to coordinate tool binary caching this way when it's related to 2 different versions. Treating KAL as a standalone binary allows for simpler make scripting and maintenance. Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>