There are two main changes here. One in the interactive-y installer/install.sh script that will ask where you want to install the new oc binary. If there was a previous oc then it will default to that directory. It knows that will definitely cause the correct binary to be executed when oc is called. So the flow goes something like this:
User has oc v3.6 at /some/strange/dir/oc
User runs installer/install.sh
installer/install.sh prompts for removal of oc
installer/install.sh asks where to install the new oc, defaults to /some/strange/dir/
The second change is in the Ansible installer, which just performs a basic check and bails out with an error message if oc is not the correct version.
maleck13
commented
6 years ago
@maleck13 Would you mind taking a look?
There are two main changes here. One in the interactive-y
installer/install.shscript that will ask where you want to install the newocbinary. If there was a previousocthen it will default to that directory. It knows that will definitely cause the correct binary to be executed whenocis called. So the flow goes something like this:oc v3.6at/some/strange/dir/ocinstaller/install.shinstaller/install.shprompts for removal ofocinstaller/install.shasks where to install the newoc, defaults to/some/strange/dir/The second change is in the Ansible installer, which just performs a basic check and bails out with an error message if
ocis not the correct version.There is also a PR up at (https://github.com/andrewrothstein/ansible-openshift-origin-client-tools) to resolve another case where a new
ocwon't be installed by the Ansible installer under certain circumstances.I'll leave this open until that is merged and make the needed changes here after it's merged.
This resolves #221