When a repository is generated without --url, the packages in that
repository do not have FQDNs. In this case, the URL prefix (FQDN plus
base path) should be derived from the repository's base URL. This seems
to be a regression that crept in around Helm 2.2.0. This is now fixed.
Closes#2315Closes#2510
* Adds update option to plugin command
Fixes issues/2385 - helm install silently updates the plugin, if it pre-existed
* Added tests for new methods for plugin update
* Updated docs
* Updated review comments :)
* Return error exit code when there is error
Updated the 'helm completion' command to take in the shell
as a parameter. Currently acceptable options are 'bash' and
'zsh'. Also fixed the completions to work with zsh in a manner
similar to what kubectl does.
Also updated the docs to reflect this change.
Closes#2201
Protoc was updated a little while ago and we are likely to get more
people using it. This should avoid weird merge conflicts and bump us
to the latest version
It is now possible to create plugins with chart download capabilities for custom, non-http protocols.
Furthermore it is possible to reuse helm packages to implement alternative clients with these custom downloader functions.
A lot of community members are looking at `helm serve` as a production webserver to host their
charts. There are much better solutions out there like s3, wabs or gcs for cloud storage and
nginx, haproxy or apache for DIY dedicated web servers. Steering users in the right direction
will help users make the right decision when it comes to serving their charts in production.
This provides the Chart.yaml field `tillerVersion`, which is a semver
range. It allows users to choose to constrain a chart to a specific
version.
The reason for this is that we keep introducing new template functions,
but we have no way of saying "this chart will only work with Tiller
newer than...".
The check on version is _only_ done on Tiller. The client does not check
at all, since it does not do any template expansion on its own.