Description

This fixes issue #83. Without this improvement, users cannot Draft Kubernetes Deployment and Services without a local k8s context (kubeconfig).

This also fixes a bug with #80.

#80 swaps how ensureDraftBinary works. This was the pattern introduced by that PR

   const downloadResult = await longRunning(`Downloading Draft.`, () =>
      getAsyncResult(ensureDraftBinary())
   );
   if (!downloadResult) {
      vscode.window.showErrorMessage('Failed to download Draft');
      return undefined;
   }

This pattern will enter theif (!downloadResult) even when Draft is correctly installed which is not the intent. The reason is ensureDraftBinary() was switched to return an errorable in #80 which getAsyncResult will extract the result or throw in the case of error. When ensureDraftBinary() is successful, it doesn't actually return a result. This results in the if (!downloadResult) { being inadvertently evaluated as true.

This is simply fixed by removing the if (!downloadResult) { entirely. getAsyncResult will throw if ensureDraftBinary fails and thrown errors result in an equivalent error message to vscode.window.showErrorMessage (throwing is actually better because it also adds a "report error" button to the message).

Fixes #83

Type of change

Please delete options that are not relevant.

• 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 not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Tested locally

Should be tested by PMs before release. Sometime we need to create full integration tests for this project. https://github.com/redhat-developer/vscode-extension-tester is promising. This is out of scope for this PR, though.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules