fix(shopware): omit initContainers, extraContainers, extraEnvs when not configured

[DeividsP-P]

Problem

When initContainers, extraContainers, or extraEnvs are not set in values, these fields are rendered unconditionally as null in the Store CRD manifest:

initContainers:
extraContainers:
extraEnvs:

The Kubernetes API server rejects this because the Store CRD schema declares these fields as type: array, and null is not a valid array. This causes an error on apply:

Store.shop.shopware.com "shopware" is invalid: [
  spec.container.initContainers: Invalid value: "null": spec.container.initContainers in body must be of type array: "null",
  spec.container.extraContainers: Invalid value: "null": spec.container.extraContainers in body must be of type array: "null"
]

Fix

Wrap each field with a guard so it is only emitted when it has content:

• initContainers: only rendered when container.initContainers is set or sidecarLogging is enabled
• extraContainers: only rendered when container.extraContainers is set or fpm is configured with a non-dynamic process manager
• extraEnvs: only rendered when container.extraEnvs is set

The fix is a minimal, idiomatic Helm change — no helpers or logic outside store.yaml are required. All existing behaviour when the fields are configured is preserved exactly.

[Patrick Derks (TrayserCassa)]

Hey, thanks for the PR
I thought this would be tested by the e2e pipeline, because it's just a limited one and run this install:

helm install test --namespace test charts/shopware \
            --set rustfs.storageclass.dataStorageSize=100Mi \
            --set rustfs.storageclass.logStorageSize=100Mi \
            --set valkeyapp.master.resources.requests.cpu=200m \
            --set valkeysession.master.resources.requests.cpu=200m \
            --set valkeyworker.master.resources.requests.cpu=200m

So this will also end in this result in the store:

    imagePullSecrets:
    topologySpreadConstraints:
    nodeSelector:
    affinity:
    labels:
    annotations:
    initContainers:
    extraContainers:

So in the kind cluster this was not an issue. How do you deploy this helm-chart? With argo or flux maybe? Then we need to make sure to double check this.

[DeividsP-P]

Hey, thanks for the PR I thought this would be tested by the e2e pipeline, because it's just a limited one and run this install:

helm install test --namespace test charts/shopware \
            --set rustfs.storageclass.dataStorageSize=100Mi \
            --set rustfs.storageclass.logStorageSize=100Mi \
            --set valkeyapp.master.resources.requests.cpu=200m \
            --set valkeysession.master.resources.requests.cpu=200m \
            --set valkeyworker.master.resources.requests.cpu=200m

So this will also end in this result in the store:

    imagePullSecrets:
    topologySpreadConstraints:
    nodeSelector:
    affinity:
    labels:
    annotations:
    initContainers:
    extraContainers:

So in the kind cluster this was not an issue. How do you deploy this helm-chart? With argo or flux maybe? Then we need to make sure to double check this.

Yes, those values you provided will also end up causing issues if not set.
We're deploying with ArgoCD.

[Patrick Derks (TrayserCassa)]

Bug which is related to our pipeline:
#268

So for me this is clear, our e2e pipeline should fail, because the generated helm-chart is not valid. It's valid for helm install but not for helm template | kubectl apply -f -

But nothing you should worry about for now, we will fix this later.

[Patrick Derks (TrayserCassa)]

Your changes are added to helm-chart version 0.0.59 and it's now live. Again thank you for the PR 💙

[DeividsP-P]

Your changes are added to helm-chart version 0.0.59 and it's now live. Again thank you for the PR 💙

Thanks a lot for merging and deploying it
After removing the placeholder values, a few more issues showed up, so I fixed those as well in a follow-up PR: #270