-
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
minikube service opens in browser when it should not #5789
Comments
This sounds like a regression, possibly caused by #5718. Perhaps the urlMode logic got inverted? /cc @nanikjava |
Looks like the logic moved from pkg/minikube/servcice/service.go to cmd/minikube/cmd/service.go between 1.3.1 and 1.5.1. |
This might improve matters; haven't tried it yet
|
@retracile - Thanks, I'm working on a PR now with an integration test to avoid future similar breakage. This definitely revealed a short-coming in our testing. |
Cool, thanks. :) |
A quick local test shows that change fixes it for me, and |
@retracile - Do you mind checking if #5790 looks good to you? You can test it on macOS by using:
|
There's no newline in the Tangent: Under some situations I'm also seeing a |
The newline seemed incorrect to me, so I removed it out. I could preserve if it it's useful. What command are you you seeing the * prefix? |
*NIX commands generally include the newline at the end; otherwise you wind up with your shell prompt tacked on the end of the output (when using it interactively). When using it within a script, it works either way. |
Good point. Will add newline back.
…On Wed, Oct 30, 2019, 12:13 PM retracile ***@***.***> wrote:
*NIX commands generally include the newline at the end; otherwise you wind
up with your shell prompt tacked on the end of the output (when using it
interactively). When using it within a script, it works either way.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#5789?email_source=notifications&email_token=AAAYYMASKYH6YWOH4KBGLQLQRHMF3A5CNFSM4JG4WQQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECVOGFI#issuecomment-548070165>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAYYMB7PGDFOIHQCZCHQ5DQRHMF3ANCNFSM4JG4WQQQ>
.
|
For the Regardless, it's a separate issue from this one. |
@retracile - Regardless, it sounds wrong. If you know of a way to reproduce it, let me know. The asterisk is likely caused by a call to |
|
Reopening until we release v1.5.2 containing this fix (tomorrow). |
Fixed in v1.5.2. Thank you for reporting this issue! |
The exact command to reproduce the issue:
minikube service --namespace mynamespace --url mynodeportservice
The full output of the command that failed:
In versions of minikube through 1.3.1, this output the service URL to stdout, and did not open the URL in the default browser. In 1.5.1, it outputs the URL and the "🎉 Opening kubernetes service ..." message to stdout, and it opens in the default browser.
With --url=false, it does not open in the browser, but now it outputs an ascii-art table instead of the plain URL.
With --url=true, it behaves the same as with --url.
Based on finding #5699, I tried using --format="{{ .IP }}". That leads to even greater insanity... it emits the message about opening the service in the default browser, but then fails to do so because it tries to open a file in the current directory matching the IP address, and errors out.
Please restore the older behavior so scripts can get the URL for a service, and fix --format to not try to open the resulting string in the default browser.
The output of the
minikube logs
command:The operating system version:
Mojave
minikube 1.5.1 installed via homebrew
The text was updated successfully, but these errors were encountered: