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.
Existing helm.sh/hook-delete-policy annotation variables (hook-failed, hook-succeeded) do not allow to leave failed jobs for debugging without blocking the next job launching: every failed job must be deleted manually before the next related release is launching (installing, updating or rolling back).
New policy, before-hook-creation, removes the hook from previous release if there is one before the new hook is launched and can be used with another variable.
When "helm.sh/hook-delete-policy: hook-succeeded" is provided in a hook's annotation, Tiller will automatically delete the hook after the hook is succeeded. When "helm.sh/hook-delete-policy: hook-failed" is provided in a hook's annotation, Tiller will automatically delete the hook after the hook is failed.
Closes#1769
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
closes#2136
* Adds new annotation `helm.sh/hookWeight`
* Sorts executing hooks of similar kind in ascending order
* There is no upper or lower bounds on the weights
Protobuf 3.2 was recently released and generates a slightly different
file from the protobuf definitions. These were all changes to the
autogenerated byte array.
* 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
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.