Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>

Signed-off-by: Adam Reese <adam@reese.io>
(cherry picked from commit 45d230fc)

Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>
(cherry picked from commit 6eeec4a0)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit 809e2d99)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit 055dd41c)

(cherry picked from commit 59d5b94d)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit 106f1fb4)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit 882eeac7)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit e2da16f5)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit 40b78002)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit c4ef82be)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit ed5fba51)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit 82398667)

Signed-off-by: knrt10 <tripathi.kautilya@gmail.com>
(cherry picked from commit 45b084b2)

When the engine stored templates in the map the keys were generated
based on path and not filepath. filepath was being used in the linter
when retrieving content from the keys. On Windows the keys ended up
being different.

This change is to use path joins to create the lookup key. Since the
name path was used in the code it needed to be changed in order to
import the package.

Tests already exist and were failing on windows. This got in because
CI is not run on Windows.

Closes #6418
Signed-off-by: Matt Farina <matt@mattfarina.com>
(cherry picked from commit 11f658e2)

jsonpatch now is the same version as used in Kubernetes v0.18.8
Signed-off-by: Maartje Eyskens <maartje@eyskens.me>
(cherry picked from commit 065b7f6e)

The previous link https://docs.helm.sh/using_helm/#quickstart-guide was redirecting into https://helm.sh/ja/docs/intro/

 which is a Japanese version of the docs. I've fixed the link so it goes into the English version instead.
Signed-off-by: Tero <31454692+tero-dev@users.noreply.github.com>
(cherry picked from commit 5421c7e9)

Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
(cherry picked from commit 131510aa)

Signed-off-by: bellkeyang <bellkeyang@tencent.com>
(cherry picked from commit fbc32aea)

Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
(cherry picked from commit 4cc19d1d)

Fixes https://github.com/helm/helm/pull/8282#discussion_r458368780

Signed-off-by: Andrew Melis <andrewmelis@gmail.com>
(cherry picked from commit f9d35242)

Previously, the `helm ls --$state` operation would display outdated
releases under certain conditions.

Given the following set of releases:
```
NAME  REVISION  UPDATED                   STATUS    CHART      APP VERSION  NAMESPACE
bar   1         Wed Apr  8 16:54:39 2020  DEPLOYED  bar-4.0.0  1.0          default
foo   1         Fri Feb  7 06:16:56 2020  DEPLOYED  foo-0.1.0  1.0          default
foo   2         Mon May  4 07:16:56 2020  FAILED    foo-0.1.0  1.0          default
foo   3         Mon May  4 07:20:00 2020  FAILED    foo-0.1.0  1.0          default
foo   4         Tue May  5 08:16:56 2020  DEPLOYED  foo-0.2.0  1.0          default
qux   1         Tue Jun  9 10:32:00 2020  DEPLOYED  qux-4.0.3  1.0          default
qux   2         Tue Jun  9 10:57:00 2020  FAILED    qux-4.0.3  1.0          default
```

`helm ls --failed` produced the following output:
```
NAME  REVISION  UPDATED                   STATUS    CHART      APP VERSION  NAMESPACE
foo   3         Mon May  4 07:20:00 2020  FAILED    foo-0.1.0  1.0          default
qux   2         Tue Jun  9 10:57:00 2020  FAILED    qux-4.0.0  1.0          default
```

Including the `qux` release in that `helm ls --failed` output is not
controversial; the most recent revision of `qux` was not successful
and an operator should investigate.

Including the `foo` release in the output, however, is
questionable. Revision 3 of `foo` is _not_ the most recent release of
`foo`, and that FAILED release was fixed in a susubsequent upgrade. A
user may see that FAILED deploy and start taking inappropriate
action. Further, that issue was fixed months ago in this example --
troubleshooting an old deploy may not be safe if significant changes
have occurred. Concern over this behavior was raised in
https://github.com/helm/helm/issues/7495.

This behavior applied to all the state filter flags (--deployed,
--failed, --pending, etc.), and a user could pass multiple state
filter flags to a single command. The previous behavior can be
summarized as follows:

For each release name, all release revisions having any of the
supplied state flags were retrieved, and the most recent revision
among these was returned (regardless of whether a newer revision of an
unspecified state exists).

This change request alters the helm list action to match user
expectations such that only "current" releases are shown when
filtering on release state. After this change, the following output
would be produced by `helm ls --failed`:

```
NAME  REVISION  UPDATED                   STATUS    CHART      APP VERSION  NAMESPACE
qux   2         Tue Jun  9 10:57:00 2020  FAILED    qux-4.0.0  1.0          default
```
The command now returns only `qux` because it is the only "current" FAILED release.

This behavior change applies to all the state filters _except_
`superseded`, which now becomes a special case. By definition, at
least one newer release exists ahead of each superseded release. A
conditional is included in this change request to maintain the
preexisting behavior (return "most recent" superseded revison for
each release name) if the superseded state filter is requested.

---

Note that there is an alternate perspective that a state filter flag
should return all releases of a given state rather than only the
"current" releases. In the above example, `helm ls --failed` with this
approach would return the following:
```
NAME  REVISION  UPDATED                   STATUS    CHART      APP VERSION  NAMESPACE
foo   2         Mon May  4 07:16:56 2020  FAILED    foo-0.1.0  1.0          default
foo   3         Mon May  4 07:20:00 2020  FAILED    foo-0.1.0  1.0          default
qux   2         Tue Jun  9 10:57:00 2020  FAILED    qux-4.0.0  1.0          default
```
Multiple FAILED `foo` revisions are included in the output, unlike the current behavior.

This approach is logical and achievable. It allows a user to find
exactly what is requested: all historical releases of a given
state. In order to achieve continuity with helm behavior, however, a
new filter (something like "current") would probably need to be
implemented and become the new default.

Given current helm behavior as well as the comments in the #7495, I
did not pursue this approach.

---

Technical details:

 - Moved list action state mask filter after latest release filter

Previously, the list operation in helm/pkg/action/list.go skipped
releases that were not covered by the state mask on _retrieval_ from
the Releases store:

```
results, err := l.cfg.Releases.List(func(rel *release.Release) bool {
		// Skip anything that the mask doesn't cover
		currentStatus := l.StateMask.FromName(rel.Info.Status.String())
		if l.StateMask&currentStatus == 0 {
			return false
		}
                ...
```
https://github.com/helm/helm/blob/8ea6b970ecd02365a230420692350057d48278e5/pkg/action/list.go#L154-L159



While filtering on retrieval in this manner avoided an extra iteration
through the entire list to check on the supplied condition later, it
introduced the possibility of returning an outdated release to the
user because newer releases (that would have otherwise squashed
outdated releases in the `filterList` function) are simply not
included in the set of working records.

This change moves the state mask filtering process to _after_ the set
of current releases is built. Outdated, potentially misleading
releases are scrubbed out prior to the application of the state mask
filter.

As written, this state mask filtration (in the new `filterStateMask`
method on `*List`) incurs an additional, potentially expensive
iteration over the set of releases to return to the user. An
alternative approach could avoid that extra iteration and fit this
logic into the existing `filterList` function at the cost of making
`filterList` function a little harder to understand.

 - Rename filterList to filterLatestReleases for clarity

Another function that filters the list is added, so update
to the more descriptive name here.

 - List superseded releases without filtering for latest

This change makes superseded releases a special case, as they would
_never_ be displayed otherwise (by definition, as superseded releases have been
replaced by a newer release), so a conditional maintains current
behavior ("return newest superseded revision for each release name")

Fixes #7495.
Signed-off-by: Andrew Melis <andrewmelis@gmail.com>
(cherry picked from commit 70f89e5f)

Signed-off-by: Chris Wells <chriswells0@users.noreply.github.com>
(cherry picked from commit 9a133850)

Most places say "Happy Helming!".

But pkg/downloader/manager.go also says "⎈Happy Helming!⎈"
Signed-off-by: Simon Shine <simon@simonshine.dk>
(cherry picked from commit 844e575d)

Signed-off-by: Bridget Kromhout <bridget@kromhout.org>
(cherry picked from commit 5684c864)

When #8156 was merged it had the side effect that all hooks were
run all the time. All the hooks were put in the flow of the
content rendered and sent to Kubernetes on every command.

For example, if you ran the following 2 commands the test hooks
would run:

    helm create foo
    helm install foo ./foo

This should not run any hooks. But, the generated test hook is run.

The change in this commit moves the writing of the hooks to output
or disk back into the template command rather than in a private
function within the actions. This is where it was for v3.2.

One side effect is that post renderers will not work on hooks. This
was the case in v3.2. Since this bug is blocking the release of v3.3.0
it is being rolled back. A refactor effort is underway for this section
of code. post renderer for hooks should be added back as part of that
work. Since post renderer hooks did not make it into a release it
is ok to roll it back for now.

There is code in th...

Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>

Show errors when linting for Chart.yaml version and appVersion fields of type non-string

Add comments about release Version variable

feat: Detect missing selector during lint

* fix(template):Issue:helm template with --output-dir doesn't write template with a hook to file

Close #7836
Signed-off-by: Dong Gang <dong.gang@daocloud.io>

* fix go file style
Signed-off-by: Dong Gang <dong.gang@daocloud.io>

* fix go file style
Signed-off-by: Dong Gang <dong.gang@daocloud.io>

fix template command use --show-only flags error in windows environment

feat(cmd): Subcommands for the completion command

Complete revision parameter for rollback command

Updating for today's actual milestone practices

Signed-off-by: Bridget Kromhout <bridget@kromhout.org>

Signed-off-by: Bridget Kromhout <bridget@kromhout.org>

Fix some go-lint warnings

fix(cmd): display warnings on stderr

The warnings introduced when a chart has been deprecated is displayed on standard out. This is a regression for users piping the output of `helm template` from a deprecated chart to `kubectl`. This changes the error message to display on standard error instead.
Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>