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¤tStatus == 0 {
return false
}
...
```
8ea6b970ec/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>
Add a unit test that proves the digest of the received content being
checked. The check should ensure that the digest of the received content
is identical to the digest provided by the manifest in the layers[0]
descriptor. This check is currently implemented in containerd, so the
unit test ensures security in the case a breaking change is made in
containerd.
Signed-off-by: Peter Engelbert <pmengelbert@gmail.com>
Having both the `showCmd` and the `subCmd` passed to `addShowFlags()`
can easily lead to mistakes in using the wrong command.
Instead, `addShowFlags()` should only focus on the `subCmd`
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
If stat returns an error other than the directory not existing
it was unhandled. When IsDir is called in one of these situations
it causes a panic.
Closes#8181
Signed-off-by: Matt Farina <matt@mattfarina.com>
Persistent flags are available on subcommands. Status does not
need the persistent nature.
Closes#8149
Signed-off-by: Matt Farina <matt@mattfarina.com>
Since Tiller is no longer part of Helm v3, internal documentation
language about Tiller can be removed
Signed-off-by: Matt Farina <matt@mattfarina.com>
Fix `repo add` and `repo update` to use a repository cache set
using `--repository-cache` flag
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
Signed-off-by: Trond Hindenes <trond@hindenes.com>
Cobra 1.0.0 introduces support for Custom Go Completions. However,
there is a small difference compared to helm's existing solution.
The difference is that Cobra will not complete sub-commands if there
are any dynamic completion functions registered.
The way helm implemented plugin completions had the dynamic completion
function associated with the root plugin command (e.g. 2to3); with
Cobra, this prevents any of the sub-commands of the plugin to be
completed (i.e., 2to3 <TAB> will not show the static sub-commands).
The solution is to only register the dynamic completion function for a
plugin command that doesn't have any further sub-commands. This allows
all sub-commands to be completed properly, and when there are no more
levels of sub-commands, the dynamic completion is called.
This commit had to make two changes to achieve this:
1- refactor the load_plugins.go file to extract the logic to call
the plugin.complete executable (for dynamic completions), so that
it could be added to each final sub-command.
2- load the static completion not only for the "completion" command like
before, but also for the "__complete" command, so that when the
__complete command is called for dynamic completion of a sub-command,
it is aware of the sub-command in question.
The second change is also valuable for the future support of completion
for the Fish shell. Completion for the fish shell uses the __complete
command not only for dynamic completions but also for basic command and
flag completion. This implies that the __complete command must be aware
of the plugins sub-commands, and therefore that the plugin's static
completion be loaded.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
Since we've moved to Go 1.14, golangci-lint has been silently failing.
This commit updates to a compatible version.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
* Fixing issue with PAX headers in plugin archive
PAX Headers can be added by some systems that create archives. Helm
should ignore them when extracting.
There are two PAX headers. One is global and the other is not. Both
are ignored. The test adds only the PAX global header because the
Go tar package is unable to write the header that is not global.
Closes#8084
Signed-off-by: Matt Farina <matt@mattfarina.com>
* Removing the PAX header test as it is not working
The PAX header test was making a WriteHeader call and ignoring the
error. When writing the type TypeXHeader it was causing an error
that was being silently ignored. The Go tar package cannot write
this type and produces an error when one tries to. The error reads
"cannot manually encode TypeXHeader, TypeGNULongName, or TypeGNULongLink
headers"
Signed-off-by: Matt Farina <matt@mattfarina.com>
* Adding check of returned error in test
Adding a check for the returned error to make sure a non-nil value
is not returned.
Signed-off-by: Matt Farina <matt@mattfarina.com>
When installing Helm, the following warning gets printed on the console:
Downloading https://get.helm.sh/helm-v2.16.6-linux-amd64.tar.gz
Preparing to install helm and tiller into /usr/local/bin
helm installed into /usr/local/bin/helm
tiller installed into /usr/local/bin/tiller
main: line 178: which: command not found
Run 'helm init' to configure helm.
The 'which' command is optional, and not always installed on all
environments (like a Fedora container). Instead, use 'command -v' to
detect if the executable is in the $PATH.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
* fix: make the linter coalesce the passed-in values before running values tests
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
* fixed typo
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>