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.
Each maintainer can have an optional URL. There are seceral use
cases for providing a URL instead of an email address:
- The case where a maintainer wants to hide their email address
behind a webform for personal security
- When the maintainer is an organization and feedback should
go to an issue queue
This change:
- Adds the proto field for url
- Updates the generated files for the chart proto
- Includes linting for the url
- Updates the docs to include the url
Closes#3056
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
This change introduces the concept of Rudders - pluggable modules that
Tiller communicates with via grpc, which allow to decouple orchestration
logic from Tiller into separate service.
This commit consists of simple Rudder implementation which does exactly
the same thing as built in Tiller orchestrator - it creates all k8s
objects from provided manifest without orchestrating them.
--experimental-release flag is introduced to enable this behaviour.
This change allows to use the service and tiller outside of the cluster.
Following commits will add Rudder to helm deployment.
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.
This feature adds the ability to selectively control the loading of charts using entries in top chart's values.
When 'helm install --set tags.mytag=true', charts with that tag will be enabled unless disabled in parent by condition.
When 'helm install --set mychart.enabled=true', charts with that yaml path specified will be enabled.
Closes#1837
* 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
The --reset-values flag on upgrade instructs Tiller to reset the
upgraded release to the chart's built-in values.yaml, and ignore the
last install's overridden values.
Closes#1569
Installs, rollback, upgrade, and delete now accept a `--timeout` flag
that allows the user to specify the maximum number of seconds that
any kubernetes command can take.
Closes#1678