Some fields were introduced to Chart metadata after Alpha.4, but are not
going to be used ever. So we made the decision to remove them before we
get stuck with ugliness.
This should not break compatibility, since these fields were not used.
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.
Fixed tests
Adding chart name linter
Add lint error
Moving to blocks
Moving to method
Moved lint rules to functions
Semantic version validation
Linting engine
Adding sources and home validations
Sharing file loading
Sharing file loading
Rolling back readme
Rewriting other linters
Fixing tests
Typo
Using chart.Metadata
Fixing format
Adding UNKNOWN in Engine
Adding tabs
Fixing tabs
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.
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.
1. install command loads chart archive.
2. invokes helm api to transform the pkg/chart.Chart type
to it's proto model.
3. the client then establishes a connection to tiller.
4. sends InstallReleaseRequest, receives InstallReleaseResponse.
todo (for complete install):
- walk pkg/chart.{Values,Deps,Templates} types and populate proto
definitions for various apis/messages.