The minikube ssh command always returns with an exit code 0, even if it fails.
minikube ssh "nonexistingcommand" && minikube ssh "date"
The second command should not be executed, because the first one failed.
Confirmed in v0.33.0:
$ minikube ssh "ls /yy" && echo $status
ls: cannot access '/yy': No such file or directory
0
Definitely a WTF.
Problem in this docker/machine package. It missing error handling: https://github.com/kubernetes/minikube/blob/master/vendor/github.com/docker/machine/libmachine/ssh/client.go#L326
Looks like they already fixed this issue:
https://github.com/docker/machine/blob/master/libmachine/ssh/client.go#L328
The version of docker/machine needs to be update in current repo, but because we are using this fork, owner of that forked repo have to update it and lock file needs to be regenerated:
https://github.com/machine-drivers/machine
@tstromberg I can either make another fork and point it there or let you guys handle that.
Please don't do any more forks...
This should be fixed (https://github.com/docker/machine/commit/6c90ba4d3da9a37ebc15c4c65d61479db075fca5) by updating to v0.16.1: https://github.com/machine-drivers/machine/pull/14
When comparing the master branch, there are no more differences left - only the forking (and merges)
So could go back to docker/machine.
@afbjorklund @adubkov - Thank you for digging into this!
If the machine-drivers/machine PR blockage goes on much longer, I would certainly consider switching back to docker/machine.
@tstromberg : unfortunately the vendored vmware driver is now blocking the switch:
Solving failure: No versions of github.com/machine-drivers/docker-machine-driver-vmware met constraints:
v0.1.1: Could not introduce github.com/machine-drivers/[email protected], as it depends on github.com/docker/machine from github.com/machine-drivers/machine, but github.com/docker/machine is already marked as coming from github.com/docker/machine by k8s.io/minikube
v0.1.0: Could not introduce github.com/machine-drivers/[email protected], as it has a dependency on github.com/docker/machine with constraint ^0.13.0, which has no overlap with existing constraint master from (root)
master: Could not introduce github.com/machine-drivers/docker-machine-driver-vmware@master, as it depends on github.com/docker/machine from github.com/machine-drivers/machine, but github.com/docker/machine is already marked as coming from github.com/docker/machine by k8s.io/minikube
But now that 0.16.1 has been merged to the machine fork, it is not the end of the world...
Trying to upgrade the vendored dependency, but dep seems to be a bit grumpy...
I want to use a773edc6f013c9fab13360fea0192fd335023a16 as the new revision.
Most helpful comment
Please don't do any more forks...
This should be fixed (https://github.com/docker/machine/commit/6c90ba4d3da9a37ebc15c4c65d61479db075fca5) by updating to v0.16.1: https://github.com/machine-drivers/machine/pull/14
When comparing the
masterbranch, there are no more differences left - only the forking (and merges)So could go back to docker/machine.