Add extraVolumes and extraVolumeMounts Helm values for mounting files into the operator pod

[fredordercloud]

Summary

• Add extraVolumes and extraVolumeMounts Helm values for mounting files into the operator pod
• Enables adminSecretFileRef usage without patching the deployment
• Includes workaround for quarkus-helm bug (generates {} instead of [] for container-scoped paths)

Test plan

• ./gradlew :operator:test --tests "it.aboutbits.postgresql.helm.HelmTest"
• Default install: no volumes, no volumeMounts

[ThoSap]

Sorry but I have to close this, I told you in PR #60 that we will do this in a follow-up PR.

Your version actually uses the old workaround for Helm chart values.yaml, I changed that in PR #62.

I opened #62 two hours before this PR, for the same gap, and it carries wider test coverage, and it also moves imagePullSecrets onto the same new pattern we used instead of the workaround you carried on.

I also decided against using extraVolumes and extraVolumeMounts, which matches the convention of Bitnami charts.
The reason is that extra implies that the Deployment has already a volume on it, which is not the case with our operator.

So volumes and volumeMounts match the rest of this chart, where imagePullSecrets and affinity use the raw Kubernetes names.

[ThoSap]

The container name is hardcoded here. We should use ${quarkus.kubernetes.name} instead.

Five other paths in this file already do, including line 86 and lines 99 to 109.

A change to quarkus.kubernetes.name breaks this path silently. quarkus-helm finds no node, processValueReference does nothing, and the value never reaches the template. No build error, no test failure, just a chart that ignores extraVolumeMounts.

[ThoSap]

extraVolumes needs the same override.

This file corrects extraVolumeMounts only. I built your branch and read the generated chart:

app:
  extraVolumeMounts: []
  extraVolumes:
    - {}
  imagePullSecrets:
    - {}

So helm show values presents extraVolumes as - {}. A user who copies that block and appends a volume name ships an invalid first entry. The guard expression keeps the default install correct, so nothing breaks until a user edits the value. That is the worst moment for it to break.

[ThoSap]

containsKey passes on the broken default. extraVolumes is [{}] in the built chart, and this assertion still passes.

assertThat(appValues.get("extraVolumes")).isEqualTo(List.of());

Two further gaps in this test:

• Nothing asserts type: array and the description in values.schema.json. A missing type falls back to string, and then helm install rejects a list.
• Nothing renders the chart with a real volume. helm template needs no cluster, and it validates the values against the schema. A wrong nindent produces invalid YAML for every user who sets the value, and no current test sees that.

[ThoSap]

getFirst() hides the risk that the named container introduces.

kubernetes.yml now names a container. If that name ever stops matching quarkus.kubernetes.name, the Pod gets two containers, and getFirst() may still return the right one. A fix would look like this:

assertThat(spec.getTemplate().getSpec().getContainers())
        .singleElement()
        .satisfies(container -> {
            assertThat(container.getName()).isEqualTo("postgresql-operator");
            assertThat(container.getVolumeMounts()).isEmpty();
        });

[ThoSap]

Missing Secrets Store CSI example.

[ThoSap]

Duplicate of #62