Dynamic completion for subcommands that apply to releases

[marckhouzam]

What this PR does / why we need it:

Add dynamic completion after

helm status <TAB>
helm delete <TAB>
helm test <TAB>
helm history <TAB>

by fetching the list of releases from the cluster.

Special notes for your reviewer:

This PR puts in the foundation for dynamic completion support in Helm.
It is inspired by the dynamic completion provided by kubectl.
Both bash and zsh are handled.

As dynamic completion actually sends queries to the cluster, this PR handles the use of Helm flags that affect which cluster should be contacted:

--kubeconfig 
--kube-context 
--host 
--tiller-namespace

[technosophos]

LGTM. And a huge thanks for fixing that all up!

[technosophos]

Also, if you'd like to file a second PR against the dev-v3 branch, we'll make sure to get this into Helm 3 as well. You can CC me on that PR

[marckhouzam]

Sorry for the delay, somehow I never got the notification you had replied!
I will making a PR for dev-v3 soon.

[marckhouzam]

@technosophos I was thinking that when doing completion, the list of possible releases should be obtained using 'helm list -a'. Currently this PR does not use the -a' flag. Unless you disagree I will update the PR to use the -a' flag.

[marckhouzam]

Ok, this one is ready for the master branch. I've just added one commit that uses helm list -a -q (extra -a flag) when fetching the list of releases for completion.

I'm working on a separate PR for dev-v3.

One question: is there a way to list release that start with a specified prefix? Such as helm list --prefix prom would list all releases starting with prom?

I'm asking for two reasons
1- it may speed up completion to avoid having to fetch the list of all releases but instead to focus on the ones the user is interested in,
2- from what I understand, helm will list up to 256 releases by default. So, on a cluster of more than 256 releases, this PR will cause the completion to only offer the first 256 releases to e.g., helm status <TAB>. If the user has typed helm status prom<TAB>, the situation would not be improved as the helm list behind the scene would still fetch the first 256 releases which could completely exclude the releases starting with prom. If we could specify the prom prefix in helm list, then we would focus the completion on the releases the user cares about.
Note that I didn't want to use the --max flag to fetch more than 256 releases as it may slow down completion too much; besides what should the --max value be in this case anyway?

[marckhouzam]

While working on the version for dev-v3, I've realized I had forgotten to include helm rollback, helm upgrade and helm get * to the list of commands that should get dynamic completion of release names.

This latest commit does this.

[marckhouzam]

I realized that helm list already had a [FILTER] option. This commit uses it so that when doing dynamic completion of a release name, we only fetch the releases that start with what the user may have already typed.

The real value of this change is when there are more than 256 releases to list. By using the filter, we greatly reduce the chance of the release the user wants being beyond the 256 limit.

[marckhouzam]

I haven't forgotten about adding this to dev-v3. The issue is that dev-v3 needs a newer version of Cobra for things to work properly. I've reached out to the Cobra project to create a new release, which they've agreed to do. Once it is ready, I'll be able to post this feature for dev-v3.

[bacongobbler]

LGTM! @marckhouzam do you need to bump cobra to 0.0.4 here as well, or is this good to merge? Let me know :)

[marckhouzam]

@bacongobbler Thanks for the review! I just reverted a commit that was part of this PR because I realized it was a hack for which the real fix is in PR #5680 .

As for Cobra, the currently used commit is sufficient for this PR. I think moving to 0.0.4 is a good idea as it brings a couple of minor fixes but should be done independently of this PR. If you want to move to 0.0.4, I can make a new PR for it. Just let me know.

So, this PR is good to commit.

Thanks!

[marckhouzam]

Oh, and the force push was because the revert commit did not have the signed-off-by at the end so the DCO check failed. I amended the commit and forced pushed on my branch.

[bacongobbler]

Awesome! Bumping Cobra would be a good idea to keep Helm 2 and Helm 3 in sync, but if it's not necessary for this PR, we can tackle bumping cobra in a followup PR. Feel free to make a new PR if you'd like :)

Thanks for responding so quickly and addressing that commit. This looks good to merge. Thanks so much for following through with this!