Going along the readme for the common package, it's suggested many times
to use the templates with no values inside, for example:
```
{{- template "common.ingress" (list . "mychart.ingress") -}}
{{- define "mychart.ingress" -}}
{{- end -}}
```
This will give the following error:
```
Error: rendering template failed: assignment to entry in nil map
```
By adding empty dict defaults, we can fix the code and respect the README
Signed-off-by: Javier Domingo Cansino <javierdo1@gmail.com>

README.md

Common: The Helm Helper Chart

This chart is designed to make it easier for you to build and maintain Helm
charts.

It provides utilities that reflect best practices of Kubernetes chart development,
making it faster for you to write charts.

Tips

A few tips for working with Common:

Be careful when using functions that generate random data (like common.fullname.unique).
They may trigger unwanted upgrades or have other side effects.

In this document, we use RELEASE-NAME as the name of the release.

Resource Kinds

Kubernetes defines a variety of resource kinds, from Secret to StatefulSet.
We define some of the most common kinds in a way that lets you easily work with
them.

The resource kind templates are designed to make it much faster for you to
define basic versions of these resources. They allow you to extend and modify
just what you need, without having to copy around lots of boilerplate.

To make use of these templates you must define a template that will extend the
base template (though it can be empty). The name of this template is then passed
to the base template, for example:

A limitation of the Go template library is that a template can only take a
single argument. The list function is used to workaround this by constructing
a list or array of arguments that is passed to the template.

The common.service template is responsible for rendering the templates with
the root context and merging any overrides. As you can see, this makes it very
easy to create a basic Service resource without having to copy around the
standard metadata and labels.

Each implemented base resource is described in greater detail below.

common.service

The common.service template creates a basic Service resource with the
following defaults:

Service type (ClusterIP, NodePort, LoadBalancer) made configurable by .Values.service.type

Named port http configured on port 80

Selector set to app: {{ template "common.name" }}, release: {{ .Release.Name | quote }} to match the default used in the Deployment resource

The above template defines two services: a web service and a mail service.

The most important part of a service definition is the ports object, which
defines the ports that this service will listen on. Most of the time,
selector is computed for you. But you can replace it or add to it.

common.deployment

The common.deployment template defines a basic Deployment. Underneath the
hood, it uses common.container (see next section).

By default, the pod template within the deployment defines the labels app: {{ template "common.name" . }}
and release: {{ .Release.Name | quote } as this is also used as the selector. The
standard set of labels are not used as some of these can change during upgrades,
which causes the replica sets and pods to not correctly match.

The above example creates a Deployment resource which makes use of the
common.container template to populate the PodSpec's container list. The usage
of this template is similar to the other resources, you must define and
reference a template that contains overrides for the container object.

The most important part of a container definition is the image you want to run.
As mentioned above, this is derived from .Values.image by default. It is a
best practice to define the image, tag and pull policy in your charts' values as
this makes it easy for an operator to change the image registry, or use a
specific tag or version. Another example of configuration that should be exposed
to chart operators is the container's required compute resources, as this is
also very specific to an operators environment. An example values.yaml for
your chart could look like:

common.ingress

The common.ingress template is designed to give you a well-defined Ingress
resource, that can be configured using .Values.ingress. An example values file
that can be used to configure the Ingress resource is:

common.fullname.unique

The common.fullname.unique variant of fullname appends a unique seven-character
sequence to the end of the common name field.

This takes all of the same parameters as common.fullname

Example template:

uniqueName: {{ template "common.fullname.unique" . }}

Example output:

uniqueName: release-name-fullname-jl0dbwx

It is also impacted by the prefix and suffix definitions, as well as by
.Values.fullnameOverride

Note that the effective maximum length of this function is 63 characters, not 54.

common.name

The common.name template generates a name suitable for the app label. It is used like this:

app: {{ template "common.name" . }}

The following different values can influence it:

# By default, name uses '{{ .Chart.Name }}'. This# overrides that and uses the given string instead.nameOverride: "some-name"# This adds a prefixnamePrefix: "pre-"# This appends a suffixnameSuffix: "-suf"# Global versions of the aboveglobal:
namePrefix: "pp-"nameSuffix: "-ps"

Most of the common templates that define a resource type (e.g. common.configmap
or common.job) use this to generate the metadata, which means they inherit
the same labels, annotations, nameOverride, and hook fields.