After discussing similar changes in #6866, we decided to make sure all
JSON and YAML output uses lower snake case names as is generally standard
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
This is a follow up to discussion in #6663 that clarifies exactly what the
validate flag is doing. It isn't meant to be a generic schema validator, but
rather validates the manifests against the current cluster as if it was
going to be installing them.
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
This code was ported over from PR #5038, #6738 which were originally for helm
v2. The code contains functions from golang/dep/internal/fs for renaming files.
Signed-off-by: Yagnesh Mistry <ysh@live.in>
This port fixes the bug #6820 for helm3
which was fixed in helm2 with the pull request 4850
https://github.com/helm/helm/pull/4850
Signed-off-by: Lam Le <lam281990@gmail.com>
The sorting method for manifests contained a check to see if the API
version existed. This violates separation of concerns as the sorter
should just sort and leave validation to other parts of the code.
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
- replace `helm repo search` with `helm search repo`
- re-clarify that the --version flag accepts a semver range
Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>
To make digests include information about Chart.yaml dependencies, not
only the lock file, digest calculation is changed to accept both
contents. This terminates the `dep build` command if Chart.yaml
dependencies have been updated so that `dep up` should be executed
properly, to prevent downloading wrong versions or mismatched subcharts.
Note that previous Helm cannot know whether Chart.yaml dependencies were changed
or not since the Chart.lock's digest is calculated by only Chart.lock
contents, which don't include information about SemVer ranges and extra
dependency fields such as aliases, conditions, and tags. Specially,
SemVer can be written as a version range in Chart.yaml, but Chart.lock
has the specific, resolved version of that range.
Signed-off-by: Hang Park <hangpark@kaist.ac.kr>
v3 port of #6792
After doing some more digging, I found out that updating the status
of an `Ingress` object is completely optional. Because of this, Helm
cannot support ingresses with the `--wait` flag because there is no
standard way to identify that they are ready
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
Fixes the regression in helm-3.0.0-beta.5 that swallows and rounds any non-zero exit status greater than 1 from a helm plugin to `1`.
This, for example, breaks `helm-diff` which relies on helm able to return `2` when `helm-diff` returned `2`.
Closese #6788
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>