This is the fix for only one particular, but important case.
The case when a new resource has been added to the chart and
there is an error in the chart, which leads to release failure.
In this case after first failed release upgrade new resource will be
created in the cluster. On the next release upgrade there will be the error:
`no RESOURCE with the name NAME found` for this newly created resource
from the previous release upgrade.
The root of this problem is in the side effect of the first release process,
Release invariant says: if resouce exists in the kubernetes cluster, then
it should exist in the release storage. But this invariant has been broken
by helm itself -- because helm created new resources as side effect and not
adopted them into release storage.
To maintain release invariant for such case during release upgrade operation
all newly *successfully* created resources will be deleted in the case
of an error in the subsequent resources update.
This behaviour will be enabled only when `--cleanup-on-fail` option used
for `helm upgrade` or `helm rollback`.
Signed-off-by: Timofey Kirillov <timofey.kirillov@flant.com>
* Refactor test run to separate method
This will allow us to parallelise it more easily
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add --parallel flag to helm test
(No functionality in this commit)
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Run helm tests in parallel with --parallel flag
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add a mutex to helm test message streams
This is to protect against data races when running tests in parallel.
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add tests for --parallel flag
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add concurrency limit for parallel helm tests
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add test for concurrency limit
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Fix rebase introduced errors
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
When 'helm <install|upgrade> --render-subchart-notes ...' is run, this will include
the notes from the subchart when rendered via Tiller.
Closes#2751
Signed-off-by: jgleonard <jgleonard@gmail.com>
This adds support for installing CRDs well before any other resource
kinds are installed.
This PR introduces a new hook, `crd-install`, that fires before
manifests are even validated. It is used to install a CRD before any
other part of a chart is installed.
Currently, this hook is _only implemented for install_. That means we
currently cannot add new CRDs during `helm upgrade`, nor can they
be rolled back. This is the safest configuration, as the update/rollback
cycle gets very challenging when CRDs are added and removed.
* This is a simple mvp which processes a test definition with the
hook annotation for test when you run `helm test [release]`
* helm client cmd, proto def, tiller logic
The --reset-values flag on upgrade instructs Tiller to reset the
upgraded release to the chart's built-in values.yaml, and ignore the
last install's overridden values.
Closes#1569
Installs, rollback, upgrade, and delete now accept a `--timeout` flag
that allows the user to specify the maximum number of seconds that
any kubernetes command can take.
Closes#1678
This adds support for the following 'helm list' flags:
- all: show all release types
- deleted: show deleted releases
- deployed: show deployed releases
- failed: show failed releases
These flags can be toggled. Only '--deployed' is turned on by default.
On the server side, Tiller's list function can now filter based on a
slice of release.Status_Code filters. While the client only supports a
subset, the server supports all known release.Status_Code types.
Closes#973
This includes a substantial bit of unit test improvements. Also, in
order to allow us to tests command line args (which translate to
helm.Option objects), I had to add a new interface to pkg/helm.
Previously, paging used the last release name of the current set to ask
for more results. Now switched to using the first name of the next set.
Not sure I like this method. It makes the user experience more
complicated.
This adds support for filtering list results. Filter strings are
passed from Helm to Tiller, where they are compiled as regular
expressions and executed against the list of releases. Only matching
releases are returned.
Filters are applied before limits and sorts.