Add a soft failure if version lookup fails

[rgee0]

Signed-off-by: Richard Gee [email protected]

Description

Currently if an error is returned from the Version lookup against GitHub the CLI will exit with an error. This is unnecessary as the version lookup is an informational item.

This change removes the error in favour of a message to the terminal to inform the user that a version lookup wasn't possible.

There is an additional benefit in not bubbling up the error message. findRelease() which is used to determine whether there is a later release was written for a specific tool (kubeseal) and if the location header that is returned is zero-sized the error message passed back is specific to kubeseal. This would add further confusion for the user who may have just installed a fully functional CLI.

Motivation and Context

• I have raised an issue to propose this change (fixes [Suggestion] Suppress error output when GitHub version check fails #874)

How Has This Been Tested?

% faas version
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|

CLI:
 commit:  0451db85faebbc4b2c9c69c8af64686ff6617825
 version: 0.14.7
Unable to find latest version online error: Head "https://github.com/openfaas/faas-cli/releases/latest": dial tcp 127.0.0.1:443: connect: connection refused
% echo $?
1
% ./faas-cli version
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|

CLI:
 commit:  d08553ed3f60fd33ee7b7d3ee35e9738d6e0e3c8-dirty
 version: 0.6.13-397-gd08553ed
Unable to determine from GitHub whether a later CLI version is available.
% echo $?           
0

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s
• I have added tests to cover my changes.
• All new and existing tests passed.