Skip to content
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

Shorten minikube version output #7322

Closed
peterlin741 opened this issue Mar 30, 2020 · 7 comments · Fixed by #7325
Closed

Shorten minikube version output #7322

peterlin741 opened this issue Mar 30, 2020 · 7 comments · Fixed by #7325
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@peterlin741
Copy link
Contributor

peterlin741 commented Mar 30, 2020

The output of minikube version is currently:

minikube version: v1.9.0
commit: 48fefd43444d2f8852f527c78f0141b377b1e42a

Whereas I expected only the version number: v1.9.0

Supporting JSON output would also work, if you need to keep the commit information, since that would also allow me to parse the version directly

@peterlin741 peterlin741 changed the title Update minikube version output Update minikube version output format Mar 30, 2020
@tstromberg
Copy link
Contributor

tstromberg commented Mar 30, 2020

I'm curious where your expectation comes from. Even kubectl version --short doesn't just respond with a version number:

Client Version: v1.16.3
Server Version: v1.18.0

I don't mind if someone adds a --short flag to minikube to get what you are looking for, but I don't feel it's necessary to update the default case.

Anyone else have thoughts here?

@tstromberg tstromberg added kind/feature Categorizes issue or PR as related to a new feature. triage/discuss Items for discussion labels Mar 30, 2020
@tstromberg tstromberg changed the title Update minikube version output format Shorten minikube version output format Mar 30, 2020
@tstromberg tstromberg changed the title Shorten minikube version output format Shorten minikube version output Mar 30, 2020
@afbjorklund
Copy link
Collaborator

afbjorklund commented Mar 30, 2020

We could also add a --format option similar to Docker ? Or perhaps just a --short like Kubernetes.

It also has a --output option, to choose between yaml and json if you don't need a full go template.

@peterlin741
Copy link
Contributor Author

I'm curious where your expectation comes from. Even kubectl version --short doesn't just respond with a version number:

Client Version: v1.16.3
Server Version: v1.18.0

I don't mind if someone adds a --short flag to minikube to get what you are looking for, but I don't feel it's necessary to update the default case.

Anyone else have thoughts here?

I saw that skaffold version returns v1.6.0. I wasn't entirely sure what the differences were between that and kubectl but I see now that kubectl version --short returns both a service and client version.

Any of the above suggested solutions work. Thanks for looking into this!

@sharifelgamal
Copy link
Collaborator

I think having a non-default --short option is totally fine, also version doesn't currently support --output but it wouldn't be hard to do.

@afbjorklund
Copy link
Collaborator

I saw that skaffold version returns v1.6.0. I wasn't entirely sure what the differences were between that and kubectl but I see now that kubectl version --short returns both a service and client version.

It's like total anarchy in the cloud native world, not only about the "silent" v in the versions...

$ runc --version
runc version 1.0.0-rc10
commit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
spec: 1.0.1-dev
$ containerd --version
containerd github.com/containerd/containerd v1.2.13 7ad184331fa3e55e52b890ea95e65ba581ae3429
$ docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b7f0
 Built:             Wed Mar 11 01:25:58 2020
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b7f0
  Built:            Wed Mar 11 01:30:32 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
$ minikube kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:58:59Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

@afbjorklund
Copy link
Collaborator

Like so:

$ ./out/minikube version
minikube version: v1.9.0
commit: a1cc3188bb6e0598de68c72f61f6a0fc9e1d2922
$ ./out/minikube version --short
minikube version: v1.9.0
$ ./out/minikube version -o json
{"commit":"a1cc3188bb6e0598de68c72f61f6a0fc9e1d2922","minikubeVersion":"v1.9.0"}
$ ./out/minikube version --output yaml
commit: a1cc3188bb6e0598de68c72f61f6a0fc9e1d2922
minikubeVersion: v1.9.0

Same as kubectl version options.

@peterlin741
Copy link
Contributor Author

peterlin741 commented Mar 30, 2020

Like so:

$ ./out/minikube version
minikube version: v1.9.0
commit: a1cc3188bb6e0598de68c72f61f6a0fc9e1d2922
$ ./out/minikube version --short
minikube version: v1.9.0
$ ./out/minikube version -o json
{"commit":"a1cc3188bb6e0598de68c72f61f6a0fc9e1d2922","minikubeVersion":"v1.9.0"}
$ ./out/minikube version --output yaml
commit: a1cc3188bb6e0598de68c72f61f6a0fc9e1d2922
minikubeVersion: v1.9.0

Same as kubectl version options.

Looks great! We would be mainly be using the ./out/minikube version -o json flags, but good to know that the other options are available

@tstromberg tstromberg removed the triage/discuss Items for discussion label Jun 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants