- Add ability to test for nested non-existent keys
- Add test cases for nested null values
- Minimalist fix for nested null key test cases
- Add missing metadata to integration test
Signed-off-by: Adam Eijdenberg <adam.eijdenberg@digital.gov.au>
The 'app.kubernetes.io/version' label was not being rendered as
expected. It was appending onto the label before it and also
the next label label was appending onto it on the same line.
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
This commits adds the possibility to back Tiller (or the future
Tiller-less Helm CLI) with any SQL database (only postgres has been
tested so far) to store release information.
The main motivation for this commit was to use a storage backend that
would allow releases larger that 1MB in size (ConfigMap or Secret
drivers don't, because of limits on value size in the underlying etcd
key-value store).
Signed-off-by: Étienne Lafarge <etienne.lafarge@gmail.com>
Co-authored-by: Elliot Maincourt <e.maincourt@gmail.com> (@emaincourt)
Co-authored-by: Paul Borensztein <hi@0x01.fr> (@commit-master)
Manifest validation is done by the builder, but it requires that the schema is set before the Stream function is called. Otherwise the StreamVisitor is created without a schema and no validation is done.
Signed-off-by: Morten Torkildsen <mortent@google.com>
Makes sure CRDs installed through the crd_install hook reaches the `established` state before the hook is considered complete.
Signed-off-by: Morten Torkildsen <mortent@google.com>
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>
There was a typo in a tiller error with "released named" message, I've changed it to "a release named". Also fix a unit-test for it.
Signed-off-by: Mikhail Kirpichev <mkirpic@gmail.com>