Additional Persistance Options

[WesselAtWork]

Wanted to add additional volumes so I could persist the mappings.
Found out that there is no way to do that sadly.

Values Keys

.Values.revisionHistoryLimit

Quality of life option for people using CD applications like Flux or Argo.

Defaults to 10 to keep default behaviour

.Values.persistence

The main bulk of this PR.
Split into mappings and responses

.Values.persistence.*.enabled

Default to false for backwards compatibility.

.Values.persistence.*.accessModes

Defaults to ["ReadWriteOnce"]

.Values.persistence.*.size

Defaults to 10Gi

.Values.persistence.*.storageClassName

The difference between storageClassName: "" and the storageClassName key being omitted are significant
I am using the same trick that grafana/helm-charts uses to allow a user omit the key, or set it to "".
Helm makes this hard as "" is falsy.
If you can think of a better trick, I am all ears.

By using the storageClassName of "-" in the values, it will template to "",
and not specifying the key will not include it in the resource

Defaults to being omitted as per recommendation

.Values.extraVolumes

Templates new Volumes onto the deployment resource.
Used to attach arbitrary extra volumes.

Defaults to empty

.Values.extraVolumeMounts

Templates extra Volume Mounts on the wiremock container, used in conjunction with the above

Defaults to empty

.Values.initContainer.extraVolumeMounts

Templates extra Volume Mounts on the wiremock Init Container, used in conjunction with the extraVolumes key.

Defaults to empty

.Values.extraObjects

Shamelessly borrowed from grafana/helm-charts

Very useful to deploy External Secrets resources or
to Network Resources like Istio / Traefik that need the port-numbers.

See the example for usage.

Defaults to empty

Notes

Playing around, with the default of ReadWriteOnce, I observed some rolling update issues with the volume being stuck to a specific pod.
The new pod can then never get the volume becuase it's currently attached to the old one.

Fix looks to be to change the deployment stratagy.
I want your input on this.

  strategy:
    type: Recreate

Submitter checklist

• Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
• The PR request is well described and justified, including the body and the references
• The PR title represents the desired changelog entry
• The repository's code style is followed (see the contributing guide)
• Test coverage that demonstrates that the change works as expected
• For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org

[WesselAtWork]

@gitkent can you take a look at this?