When `helm install -f foo.yaml bar` is called, and then the release is
upgraded with `helm upgrade happy-panda bar`, this will now re-use the
values that were submitted with `-f foo.yaml`. The same is true for
values specified with `--set`.
Closes#1227
If a release has been deleted, `install --replace` will work but the release
status will still be "deleted". This means that subsequest attempts to
change the release will fail. Upgrading the release instead will prevent
such zombie releases.
Closes#1131
This modifies `helm status` to return info about deleted and failed
releases. We do our best to retrieve info for releases that were
partially deployed.
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 limits the number of characters in a release name to 14. This
preserves 10 characters for customizing the `name:` field in charts.
Relates to #1071
This stops a repeat deletion from sending requests all the way to
Kubernetes, and gives a clear error message when a deletion is requested
on an already deleted resource.
Relates to #972
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.
Template paths were relative to the chart that contained them, which
meant that all templates were named 'template/SOMETHING'. This made it
trivially easy to hit namespace collisions as in #933.
Template path names are essentially opaque strings so this patch simply
changes them to be qualified by parent chart.
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.
This commit finally ties `helm install` together with the Kubernetes
client library to make an end-to-end trip.
There were several small fixes to go on both client and server side,
along with some changes to proto to support better error reporting.
The alpine chart has been updated to exhibit how the new Helm works.
This adds support for dry run on install, as well as providing
enough info for an install to display (verbose) manifests. While
doing this, I ended up just storing the rendered manifests for
simplicity.