The `hull.config` section

Within the config section you can configure general settings for your Helm chart. It is divided into two subsections, config.general and config.specific.

The `hull.config.general` section

In contrast to the hull.config.specific section, which should be populated with arbitrary data that is specific only to a single helm chart, the hull.config.general section should be used to define everything that is not particular to a unique application. On the one hand it holds configuration options which are relevant for all HULL based charts but also leaves room under the hull.config.general.data entry to define your own data fields which ideally are modeled the same way in other helm charts. For example, if several applications in a product suite depend on the same endpoints, you could model these endpoints uniformly under the hull.config.general.data property in all relevant charts and thereby having your helm charts interface in the same way with e.g. a continuous deployment pipeline.

hull.config.general has only the following sub-fields:

nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
errorChecks
debug
render
postRender
serialization
rbac
data
metadata

The following table gives more details on all available fields and subfields:

Parameter	Description	Default	Example
`nameOverride`	The name override is applied to values of metadata label `app.kubernetes.io/name`. If set this effectively replaces the chart name here.
`fullnameOverride`	If set to a value, the fullname override is applied as a prefix to all object names and replaces the standard `<release>-<chart>` prefix pattern in object names.		`myapp`
`namespaceOverride`	If set to a value, the namespace of all created objects is set to this value. If this is not defined, the namespace of all object instances defaults to the release namespace provided to the respective helm command.		`my-namespace`
`noObjectNamePrefixes`	If set, the object instance keys directly serve as the names for the Kubernetes objects created and are never prefixed. This is technically equivalent to setting `staticName` true on each object. Note that by setting this to `true` the value of `config.general.fullnameOverride` becomes irrelevant.	`false`	`true`
`createImagePullSecretsFromRegistries`	If true, image pull secrets are created from all registries defined in this Helm chart and are added to all pods.	`true`	`false`
`globalImageRegistryServer`	If not empty the `registry` field of all container `image` fields is set to the value given here. The setting of `config.general.globalImageRegistryToFirstRegistrySecretServer` is ignored if this field is non-empty. All defined explicit `registry` settings for an `image` are overwritten with this value. Intended usage of this is to conveniently have all images pulled from a central docker registry in case of air-gap like deployment scenarios. Contrary to setting `globalImageRegistryToFirstRegistrySecretServer` to `true`, in this case the registry secret is typically defined outside of this helm chart and the registry secret's server is referenced by its name directly. If you use this feature and define the Docker registry secret outside of this Helm chart you may additionally need to add `imagePullSecrets` to your pods in case the referenced Docker registry is not insecure.	`""`	`mycompany.docker-registry.io`
`globalImageRegistryToFirstRegistrySecretServer`	If true and `globalImageRegistryServer` is empty, the `registry` field of all container `image` fields is set to the `server` field of the first found `registry` object. Note that this is the registry with the lowest alphanumeric key name if you provide multiple `registry` obejcts. Should normally be used together with setting `createImagePullSecretsFromRegistries` to `true` to benefit from autopopulated `imagePullSecrets` and accordingly set `registry`. Explicit `registry` settings for an `image` are overwritten with this value. Intended usage of this setting is to conveniently have all images pulled from a central docker registry in case of air-gap like deployment scenarios.	`false`	`true`
`errorChecks`	Options that determine in which cases HULL will generate an error on `helm install` or `helm template`. For more details see also the detailed documentation on configuring error checks Has only the following sub-fields: `objectYamlValid` `hullGetTransformationReferenceValid` `containerImageValid` `virtualFolderDataPathExists` `virtualFolderDataInlineValid`
`errorChecks.objectYamlValid`	Validate that no broken YAML is rendered	`true`
`errorChecks.hullGetTransformationReferenceValid`	Validate that all `_HT*` references point to an existing key in the `values.yaml`	`true`
`errorChecks.containerImageValid`	Validate that all `pod`'s `containers` and `initContainers` `image` sections exist and have at least a `repository` set	`true`
`errorChecks.virtualFolderDataPathExists`	Validate that all files being refered to in a ConfigMap and Secret's `data` `path` field do physically exist	`true`
`errorChecks.virtualFolderDataInlineValid`	Validate that no `null` values or missing values (which are converted to empty strings) are set for ConfigMap and Secret's `data` `inline` fields	`false`
`debug`	Options that can help with debugging chart problems. Mostly obsolete and replaced by speaking default error messages configured under `errorChecks`. Has only the following sub-fields: `renderBrokenHullGetTransformationReferences` `renderNilWhenInlineIsNil` `renderPathMissingWhenPathIsNonExistent`
`debug.renderBrokenHullGetTransformationReferences`	Global switch which if enabled will print out a string: `HULL failed with error BROKEN-HULL-GET-TRANSFORMATION-REFERENCE: Element <y> in path <x.y.z> was not found` including the `_HT*/hull.util.transformation.get` reference (`x.y.z`) and the missing key (`y`) if the transformation references a non existing dictionary key. This is useful to debug chart rendering and reduces searching for broken references because normally the installation aborts with an error on broken references (which may make it hard to pin point the problematic reference(s)). NOTE: By now any broken get reference will be signaled by a speaking helm error by default so this switch is mostly obsolete for debugging broken references. It is recomended to disable this option and fail hard on broken get references instead and analyze problems directly from the error message.	`false`	`true`
`debug.renderNilWhenInlineIsNil`	Global switch which if enabled will print out a string: `<nil>` as a `data` fields value when an `inline` spec references a `nil` pointer in a ConfigMap or Secret. If set to false, the `nil` value will be printed as an empty string in the ConfigMap or Secret `data` field. NOTE: By now any invalid inline fields will be signaled by a speaking helm error by default (meaning `hull.config.general.errorChecks.virtualFolderDataInlineValid` is `true`). Enabling this switch is mostly obsolete for debugging and it is recomended to disable this option and fail hard on invalid inline fields.	`false`	`true`
`debug.renderPathMissingWhenPathIsNonExistent`	Global switch which if enabled will print out a string: `<path missing: the_missing_path>` in a ConfigMap or Secret `data` fields value including the `the_missing_path` value which does not resolve to a file. If false, the `data` fields value will resolve to an empty string. NOTE: By now any non-existent file referenced in a path field will be signaled by a speaking helm error by default (meaning `hull.config.general.errorChecks.virtualFolderDataPathExists` is `true`). Enabling this switch is mostly obsolete for debugging and it is recomended to disable this option and fail hard on non-existing file path references.	`false`	`true`
`render`	Options to influence how HULL renders out objects as YAML. Has only the following sub-fields: `emptyAnnotations` `emptyLabels` `emptyHullObjects`
`render.emptyAnnotations`	If `true`, HULL renders out `annotations: {}` if no annotations exist for an object, if `false` the `annotations` key is omitted.	`false`	`true`
`render.emptyLabels`	If `true`, HULL renders out `labels: {}` if no labels exist for an object, if `false` the `labels` key is omitted.	`false`	`true`
`render.emptyTemplateAnnotations`	If `true`, HULL renders out `annotations: {}` in the `template` of a pod if no annotations exist for an object, if `false` the `annotations` key is omitted.	`false`	`true`
`render.emptyTemplateLabels`	If `true`, HULL renders out `labels: {}` in the `template` of pods if no labels exist for an object, if `false` the `labels` key is omitted.	`false`	`true`
`render.emptyHullObjects`	If `true`, HULL renders out arrays as empty arrays if no elements exist for some fields processed by HULL. If false, the key-value pair is ommited. This affects fields which are mapped from a dictionary in HULL configuration to a Kubernetes array in the rendered YAML. The following is a list of affected fields in HULL's object configuration: `data` in `secret` and `configmap` objects `initContainers`, `containers`, `volumes` and `imagePullSecrets` in `cronjob`,`daemonset`, `deployment`, `job` and `statefulset` `pod` objects `ports`, `env`, `envFrom` and `volumeMounts` in `initContainers`, `containers` and `volumes` in `cronjob`,`daemonset`, `deployment`, `job` and `statefulset` `pod` objects `ports` in `service` objects `rules` and `tls` in `ingress` objects `http.paths` in `rules` in `ingress` objects `webhooks` in `validatingwebhookconfiguration` and `mutatingwebhookconfiguration` `rules` in `clusterrole` and `role`	`false`	`true`
`postRender`	After HULL has fully rendered an object it is possible to manipulate the resulting YAML string. Possibilities to do so are provided as `postRender` actions here. WARNING: Use with caution as this may corrupt the YAML structure!
`postRender.globalStringReplacements`	A dictionary of replacement possibilities that may be applied to the rendered object's YAML. The main use case for this is in combination with extensive defaulting in `_HULL_OBJECT_TYPE_DEFAULT_` and `sources` object instances where it allows to inject instance specific strings into the defaulted YAML. Also, for down stream content that needs to preserve double curly braces as used in templating expressions, it allows to replace custonmizable placeholders with double curly opening and closing braces. The preconfigured mappings provided may be `enabled: true` on demand. Each mapping consists of following fields: `enabled`: execute mapping if `true` `string`: the exact string part to be replaced `replacement`: the type of value inserted instead of `string`. Can be one of the following static values `OBJECT_INSTANCE_KEY`, `OBJECT_INSTANCE_KEY_RESOLVED` and `OBJECT_INSTANCE_NAME` which are interpreted and resolved as explained below. Any other value is treated as a string value.
`postRender.globalStringReplacements.instanceKey`	If `enabled`, the `string` value will be replaced with the actual object's `instance_key` as in `hull.objects.<object_type>.<instance_key>`. The value of `replacement` is `OBJECT_INSTANCE_KEY` for this mapping.		`instanceKey:` `enabled:` `false` `string:` `_HULL_OBJECT_TYPE_DEFAULT_` `replacement:` `OBJECT_INSTANCE_KEY`
`postRender.globalStringReplacements.instanceKeyResolved`	If `enabled`, the `string` value will be replaced with the actual object's `instance_key` as in `hull.objects.<object_type>.<instance_key>` or by `hull.objects.<object_type>.<instance_key>.metadataNameOverride` if this is defined. The value of `replacement` is `OBJECT_INSTANCE_KEY_RESOLVED` for this mapping.	`instanceKeyResolved:` `enabled:` `false` `string:` `_HULL_OBJECT_TYPE_DEFAULT_` `replacement:` `OBJECT_INSTANCE_KEY_RESOLVED`
`postRender.globalStringReplacements.instanceName`	If `enabled`, the `string` value will be replaced with the actual object's rendered `metadata.name`. The value of `replacement` is `OBJECT_INSTANCE_NAME` for this mapping.	`instanceName:` `enabled:` `false` `string:` `_HULL_OBJECT_TYPE_DEFAULT_` `replacement:` `OBJECT_INSTANCE_NAME`
`postRender.globalStringReplacements.openingDoubleCurlyBraces`	If `enabled`, the `string` value (default `{+{`) will be replaced with opening double curly braces `{{`. The value of `replacement` is thus `{{` for this mapping.	`openingDoubleCurlyBraces:` `enabled:` `false` `string:` `{+{` `replacement:` `{{`
`postRender.globalStringReplacements.closingDoubleCurlyBraces`	If `enabled`, the `string` value (default `}+}`) will be replaced with closing double curly braces `}}`. The value of `replacement` is thus `}}` for this mapping.	`closingDoubleCurlyBraces:` `enabled:` `false` `string:` `}+}` `replacement:` `}}`
`serialization`	General serialization options.
`serialization.configmap.enabled`	If `enabled`, the mapped file extensions under `fileExtensions` are serialized with the given serialization method by default. If the `data` key ends with one of the mapped extensions the serialization method in the value is used to write the content to string. A specific `serialization` field on a configmaps `data` entry overwrites any default settings.	`true`
`serialization.configmap.fileExtensions`	A dictionary of mappings from file extensions to serialization methods.	`fileExtensions:` `json:` `toPrettyJson` `yaml:` `toYaml` `yml:` `toYaml`
`serialization.secret.enabled`	If `enabled`, the mapped file extensions under `fileExtensions` are serialized with the given serialization method by default. If the `data` key ends with one of the mapped extensions the serialization method in the value is used to write the content to string. A specific `serialization` field on a secrets `data` entry overwrites any default settings.	`true`
`serialization.secret.fileExtensions`	A dictionary of mappings from file extensions to serialization methods.	`fileExtensions:` `json:` `toPrettyJson` `yaml:` `toYaml` `yml:` `toYaml`
`rbac`	Global switch which enables RBAC objects for installation. If `true` all enabled RBAC objects are deployed to the cluster, if `false` no RBAC objects are created at all. RBAC objects that are deployable are: `roles` `rolebindings` `clusterroles` `clusterrolebindings`	`true`	`false`
`data`	Free form field whereas subfields of this field should have a clearly defined meaning in the context of your product suite. For example, assume all of your products or microservices (each coming as a separate helm chart) depends on the same given endpoints (authentication, configuration, ...). You might have a shared Kubernetes job executed by each helm chart which targets those endpoints. Now you could specify an external HULL `values.yaml` containing the job specification and the endpoint definition here in a way you see fit and construct an overlay `values.yaml` rendered on top of each deployment and have a unified mechanism in place.	`{}`
`metadata`	Defined metadata fields here will be automatically added to all objects metadata. Has only the following sub-fields: `labels` `annotations`
`metadata.labels`	Labels that are added to all objects. The `common` labels refer to the Kubernetes and Helm common labels and `custom` labels can be freely specified. Has only the following sub-fields: `common` `custom`
`metadata.labels.common`	Common labels specification as defined in https://helm.sh/docs/chart_best_practices/labels/ and https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/. Unless specifically overwritten with empty values (`''`) all metadata labels are automatically added to all objects according to their default definition. It should be considered to set a value for `config.general.metadata.labels.common.'app.kubernetes.io/part-of'` if the helm chart is part-of a product suite.
`metadata.labels.common.'app.kubernetes.io/managed-by'`	Managed by metadata.	`{{ .Release.Service }}`
`metadata.labels.common.'app.kubernetes.io/version'`	Version metadata.	`{{ .Chart.AppVersion }}`
`metadata.labels.common.'app.kubernetes.io/part-of'`	Part-of metadata.	`"unspecified"`
`metadata.labels.common.'app.kubernetes.io/name'`	Name metadata.	`{{ printf "%s-%s" .ChartName <hullObjectKey> }}`
`metadata.labels.common.'app.kubernetes.io/instance'`	Instance metadata.	`{{ .Release.Name }}`
`metadata.labels.common.'app.kubernetes.io/component'`	Component metadata.	`<hullObjectKey>`
`metadata.labels.common.'helm.sh/chart'`	Helm metadata.	`{{ (printf "%s-%s" .Chart.Name .Chart.Version) \\| replace "+" "_" }}`
`metadata.labels.custom`	All specified custom labels are automatically added to all objects of this helm chart.	`{}`
`metadata.annotations`	Annotations that are added to all objects. The `custom` labels can be freely specified. Has only the following sub-fields: `custom`.
`metadata.annotations.custom`	All specified custom annotations are automatically added to all objects of this helm chart.	`{}`

The `hull.config.specific` section

The hull.config.specific dictionary is a free form field that holds configuration options that are specific to the specific product contained in the helm chart. Typically the values specified here ought to be used to populate the contents of configuration files that a particular applications read their configuration from at startup. Hence the config.specific fields are typically being consumed in ConfigMaps or Secrets or represent otherwise shared values.

An example of may look like this:

hull:
  config:
    specific:
      maxDatepickerRange: 50
      defaultPoolColor: #FB6350
      updateInterval: 60000

The hull.config section

The hull.config.general section

The hull.config.specific section

The `hull.config` section

The `hull.config.general` section

The `hull.config.specific` section