Turns out that removing the quotes from the associate array
'aliashash' is still required, but because it is needed for
completion of alias commands. For example
helm dep <TAB>
does not complete as expected (as if it was 'helm dependency')
if the quotes are not removed.
This is because although bash ignores quotes when using
associative arrays, zsh does not. So when looking for an alias
aliashash[dep]
will not match the entry
aliashash["dep"]
in zsh but will for bash. Therefore, removing the quotes fixes
things.
Signed-off-by: Marc Khouzam <marc.khouzam@ville.montreal.qc.ca>
This reverts commit d2ab3f5062.
The reverted commit turned out to be a workaroud another problem.
The real fix is submitted in PR #5680
Signed-off-by: Marc Khouzam <marc.khouzam@ville.montreal.qc.ca>
- Add ability to test for nested non-existent keys
- Add test cases for nested null values
- Minimalist fix for nested null key test cases
- Add missing metadata to integration test
Signed-off-by: Adam Eijdenberg <adam.eijdenberg@digital.gov.au>
PR #5072 followed by #5406 tweaked the handling of the associative
array 'aliashash' when in zsh. However, upon further investigation
the root of the problem was the 'aliashash' was not being declared
properly as it was declared within a method and therefore not
accessible to the rest of the completion script.
The previous commit of this PR makes the necessary change to properly
declare 'aliashash' which makes the previous tweak unecessary. This
commit removes the tweak.
Signed-off-by: Marc Khouzam <marc.khouzam@ville.montreal.qc.ca>
This is a bug I ran into when working on Helm completion.
I was surprised that it didn't happen when I was using
kubectl, so I investigated and found a PR that fixed this
bug in kubectl:
https://github.com/kubernetes/kubernetes/pull/48553
I duplicated the code in this commit which:
Removes __helm_declare, which is safe to do since
`declare -F` is already replaced to `whence -w` by
__helm_convert_bash_to_zsh().
The problem was that calling "declare" from inside a function
scopes the declaration to that function only. So "declare"
should not be called through __helm_declare() but instead
directly.
To reproduce:
1- setup helm completion in zsh
2- helm --kubeconfig=$HOME/.kube/config statu<TAB>
you will get the error:
__helm_handle_flag:27: bad math expression: operand expected at end of string
Co-authored-by: Kazuki Suda <kazuki.suda@gmail.com>
Signed-off-by: Marc Khouzam <marc.khouzam@ville.montreal.qc.ca>
This commits adds the possibility to back Tiller (or the future
Tiller-less Helm CLI) with any SQL database (only postgres has been
tested so far) to store release information.
The main motivation for this commit was to use a storage backend that
would allow releases larger that 1MB in size (ConfigMap or Secret
drivers don't, because of limits on value size in the underlying etcd
key-value store).
Signed-off-by: Étienne Lafarge <etienne.lafarge@gmail.com>
Co-authored-by: Elliot Maincourt <e.maincourt@gmail.com> (@emaincourt)
Co-authored-by: Paul Borensztein <hi@0x01.fr> (@commit-master)
Flags sometimes can be used with an = sign, such as --kube-context=prod.
In this case, the variable ${flagname} retains the = sign as part of the
flag name. However, in zsh completion, an = sign cannot be part of an
index of the associative array 'flaghash' or else it causes an error.
This commits strips the = sign out when using ${flagname} as an index.
Note that this is not a big deal since flaghash is not actually used
anywhere in Helm completion. I believe it is made available by the
Cobra framework in case some completions choose to use it.
Signed-off-by: Marc Khouzam <marc.khouzam@ville.montreal.qc.ca>
As many people have requested and discussed in #3159.
The variable name are kept the same as before. Corresponding command-line flag is named, and description are written, after the existing flag for gRPC.
The scope of this change is intentionally limited to the minimum. That is, I have not yet added `--probe=false`, because it shouldn't be a blocker if we can change the port number.
Signed-off-by: Yusuke KUOKA <ykuoka@gmail.com>