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>
