-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Improve error handling for versions without v
prefix
#3766
Improve error handling for versions without v
prefix
#3766
Conversation
Can one of the admins verify this patch? |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dimitropoulos If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@@ -25,6 +25,7 @@ import ( | |||
|
|||
"github.com/blang/semver" | |||
"github.com/golang/glog" | |||
"github.com/kubernetes/minikube/pkg/version" |
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.
Is this PR missing a file?
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.
I'm not sure. could you please rephrase? I am hoping this file (and the other kubeadm one) isn't from somewhere else.
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.
The travis test failed with:
Running go tests...
pkg/minikube/bootstrapper/kubeadm/versions.go:28:2: cannot find package "github.com/kubernetes/minikube/pkg/version" in any of:
/home/travis/gopath/src/k8s.io/minikube/vendor/github.com/kubernetes/minikube/pkg/version (vendor tree)
/home/travis/.gimme/versions/go1.12.linux.amd64/src/github.com/kubernetes/minikube/pkg/version (from $GOROOT)
/home/travis/gopath/src/github.com/kubernetes/minikube/pkg/version (from $GOPATH)
make: *** [test] Error 1
The command "make test" exited with 2.
I'm not sure why this is happening though, because that package does exist as far as I know. Hmm...
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.
I mean.. it's not totally necessary because I feel pretty confident the version prefix isn't changing from v
any time soon. I just used it because I noticed it was there and figured it could (if nothing else) be clearer instead of looking like some random magic-character, you know?
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.
To pass the tests, this should be:
"k8s.io/minikube/pkg/version"
Thanks!
a2e966b
to
e11f258
Compare
@minikube-bot OK to test |
Marking as WIP until @dimitropoulos has a chance to rebase. |
v
prefixv
prefix
e11f258
to
147f686
Compare
ok so I rebased it but there seem to be some other changes that attempt to catch the same thing that have been done since I started... I'll leave it to you to decide how you want to proceed. |
A coworker clued me into what is happening with this error message:
The import is using You'll want to move which directory minikube source is stored in: I suspect when we move to Go modules that this will go away. |
perhaps I misunderstood your directions (I don't, myself, understand what the actual problem is either) but I tried to update it and it seems to still fail. |
Excellent, it looks like the failure is at least different now:
I think this can be fixed by using this for your comparison:
If you run |
Is this PR still being worked on? I believe this may be a 1-line change away from merging. |
I made the change you suggested and it appears to still be failing. when I test it locally I get:
but I can't seem to figure a way to fix it. |
@@ -427,6 +427,11 @@ func validateKubernetesVersions(old *cfg.Config) string { | |||
if nv == "" { | |||
nv = constants.DefaultKubernetesVersion | |||
} | |||
|
|||
if nv[0] != version.VersionPrefix { |
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.
To avoid the bytes/string error, this should match the check in versions.go:
if !strings.HasPrefix(nv, version.VersionPrefix) {
Alternatively, why not just allow a version to be specified without a leading v? We know what the user wants, so instead of raising the error, we could just give it to them and make their life easier:
if !strings.HasPrefix(nv, version.VersionPrefix) {
nv = version.VersionPrefix + nv
}
v, err := semver.Make(version[1:]) | ||
// ParseKubernetesVersion validates the kubernetes version as legitimate | ||
func ParseKubernetesVersion(input string) (semver.Version, error) { | ||
if !strings.HasPrefix(input, version.VersionPrefix) { |
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.
I think this check can be removed: it isn't necessary to check for the leading 'v' here because it is stripped away immediately afterwards. Just continue to use strings.TrimPrefix, and it will handle both cases perfectly.
v
prefixv
prefix
v
prefixv
prefix
As I haven't heard anything recently and I bumped into this issue myself, I took inspiration from this PR to create a new PR: #4568 |
great. thanks @tstromberg |
I always forget whether the v is required syntax. When you start minikube without the v, it currently looks like this:
I added a test or two and tried to make the error message clearer, since, after all, it isn't
""
that I passed so I (as the user) don't have much to go on to understand what it's talking about in the current error.That said.. I would be happy to just fix things up to allow either the
v
or the no-v
versions accepted for this flag. I only didn't do so because I was unsure if this was some kind of design choice. In the two places in the code (both edited in this PR) where the version is used, it is immediately stripped of itsv
anyway.