-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds --output=yaml to silence deprecation warning #138
Conversation
Seen in a run: > WARNING: This version information is deprecated and will be replaced with the > output from kubectl version --short. Use --output=yaml|json to get the full > version.
OK, so hilariously, I ran
So, bare
is being replaced with the
and Probably the right thing to do instead of adding clientVersion:
buildDate: "2022-11-09T13:28:30Z"
compiler: gc
gitCommit: 872a965c6c6526caa949f0c6ac028ef7aff3fb78
gitTreeState: clean
gitVersion: v1.25.4
goVersion: go1.19.3
major: "1"
minor: "25"
platform: darwin/arm64
kustomizeVersion: v4.5.7
serverVersion:
buildDate: "2022-02-16T11:18:16Z"
compiler: gc
gitCommit: a7a32748b5c60445c4c7ee904caf01b91f2dbb71
gitTreeState: clean
gitVersion: v1.21.10
goVersion: go1.16.14
major: "1"
minor: "21"
platform: linux/amd64
WARNING: version difference between client (1.25) and server (1.21) exceeds the supported minor version skew of +/-1 |
kubectl 1.25.4 bare `version` output says that `version --short` is deprecated, but I missed the note that the output of `version --short` will become the output of bare `version`. What's going away is what's displayed by bare `version` presently. Since we probably still want the long output in some form, let's dump it in YAML. It's YAML all the way down, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm - thanks!
Codecov Report
@@ Coverage Diff @@
## main #138 +/- ##
=======================================
Coverage 60.00% 60.00%
=======================================
Files 9 9
Lines 615 615
=======================================
Hits 369 369
Misses 244 244
Partials 2 2
|
on second thought, i can check myself, but is this backwards compatible? since we allow for folks to choose their kubectl version, i'd just want to make sure to not cause issues with it causing a failure because the flag isn't supported. |
I did not check the compatibility with older versions. I'm not super familiar with how well kubernetes sticks to semver so I just kind of assumed that these options would be available in some way in the entire 1.x series. That may be naively optimistic. |
yea, we don't really have any kind of promise around version compatibility, but a brief check in their docs shows it's supported in 1.21 (https://v1-21.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#version). their version selector actually only let's you go to 1.22 (which they say is not maintained anymore - https://v1-22.docs.kubernetes.io/docs/home/). i think we're good. thanks. |
Seen in a run: