Currently, `helm repo list -o json` returns (either `[]` or an english
"no repositories" error message, depending on whether
`$HELM_CONFIG_HOME/repositories.yaml` exists). This PR aligns the two cases
so that it always returns `[]`.
Signed-off-by: Teo Klestrup Röijezon <teo@nullable.se>
We had made the assumption that when doing shell completion, we only
needed choices that had for *prefix* what the user had typed.
However, the zsh and fish shells have a more advanced matching system
which first matches on prefix, but if no match is found, then does
more advanced matching attempts, such as sub-strings; fish even matches
on descriptions of completions.
For example,
helm status nginx<tab>
would match releases such as
ingress-nginx
ingress-nginx-release
as long as no release had a prefix of "nginx".
Such fuzzy matching can make completion even more useful for users in
cases where identical prefixes are common.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
`runTestCmd` is identical to `runTestActionCmd` except that it
* runs the command multiple times if the `repeat` property is greater
than zero,
* calls its storage `storage` instead of `store`,
* fails if the `Create` method returns an error, and
* logs a "running cmd" message.
This is most easily demonstrated by copying the functions to their own
files and diffing the files with this command:
git diff --no-index --ignore-space-change --color-words=. runTestActionCmd.go runTestCmd.go
Also, `runTestCmd` is used 32 times; `runTestActionCmd` only 1.
Signed-off-by: Simon Alling <alling.simon@gmail.com>
Before this change, several of the potential errors during the process
of signing a package were skipped.
Crucially, `Close()`ing the ReadCloser from the gpg clearsigner is the call
which actually does the signing, and so has several points of failure
which are ignored; for example, if there's a problem with the format of
the key.
Also changes the error from messageBlock() to be propagated rather than
being swallowed, and adds a test for the case where a signer fails to
sign.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
The partition value can be greater than number of replicas, in that
case no pods are rolled out. The expectedReplicas becomes a negative
number.
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#partitions
In the cases where the update does not change anything in the pod
template, the updatedReplicas value from StatefulSet status remains
unchanged. Such updates can still set some partition value, and
UpdatedReplicas is always greater than expectedReplicas. Basically,
the StatefulSet is ready / rolled-out.
In both the above scenarios, providing `--wait` flag causes it to
timeout waiting indefinitely. Because updatedReplicas can never be
negative, or be equal to the expectedReplicas for the second case.
This commit handles both the scenarios by checking if UpdatedReplicas
is smaller than expectedReplicas. If it is, then the StatefulSet is
not ready yet.
Based on the code from kubectl rollout:
a450ebd59c/pkg/polymorphichelpers/rollout_status.go (L138-L141)Closes#8674
Signed-off-by: Bhavin Gandhi <bhavin7392@gmail.com>