[marcleblanc2]

Open issues

Found in review on 2026-11-13 (review thread). This PR is a draft until the first four are settled.

1. A component override can leak into other components. The merge only copies the chart default, so a nested override changes the global value for every template rendered after it. With a global pod seccompProfile.type: RuntimeDefault and gitserver.podSecurityContext.seccompProfile.type: Unconfined, six workloads render Unconfined: gitserver, plus cadvisor, blobstore, frontend, codeintel-db, and codeinsights-db. Fix: deepCopy the global and the override too, in all four copies of the helper
2. The branch removes the redis: keep config checksum stable across chart versions #989 Redis fix. The sourcegraph.redis.conf helper, tests/redisConfigChecksum_test.yaml, and the changelog line are gone, and Git merges that without a conflict. Redis would again restart on every chart version bump when config.enabled is set
3. A default install prints the cadvisor "privileged set to false" warning. NOTES.txt reads cadvisor.containerSecurityContext.privileged, which is now an empty override; the container itself still renders privileged: true
4. Conflicts with main in values.yaml, README.md, and the syntactic code-intel worker Deployment; the fsGroup logic from Allow syntactic-code-intel-worker /tmp scratch on a per-pod PVC #987 needs porting to the merged helpers
5. "Existing overrides continue as-is" is not true for a whole-map null. frontend.containerSecurityContext: null rendered securityContext: null before, and now renders the chart defaults (runAsUser: 100 and the rest). Honor an explicit null, or add a breaking-change changelog entry
6. The global value does not reach every pod, and can produce a combination Kubernetes rejects.
   • Missed: the dind chart's private-docker-registry StatefulSet, dind gVisor mode, and executor job pods
   • A global allowPrivilegeEscalation: false renders next to privileged: true on cadvisor and dind. Kubernetes documents that combination as invalid; not run on a cluster
   • With --reuse-values, the stored old defaults act as overrides, and the global is ignored without a message
7. Not in the description or a changelog: pgsql-exporter gains allowPrivilegeEscalation: false, so the three database pods restart on upgrade; a new executor.enabled value in the k8s executor chart gates only the Deployment and ConfigMap; no chart has a changelog entry
8. Tests cover one new and one changed case. Nothing covers precedence, nested maps, nulls, the other three charts, or NOTES.txt

Not tested on a cluster: the first three were reproduced with helm template and a client-side dry run, and with the conflicts unresolved there is no chart to deploy that matches what would merge.

Problem:

• When customers need to modify containerSecurityContext and / or podSecurityContext, they generally need to modify the same on all containers or all pods
• For example, customers running in RedHat OpenShift must set runAsUser, runAsGroup, and fsGroup on all containers / pods to the same UID / GID assigned to their Kubernetes namespace (OpenShift Project)
• Specific customer examples provided in Slack thread
• This creates a bloated and hard-to-maintain override file, with scads of duplicate lines, or relies on using YAML hacks

Solution:

• Create global configs, .Values.sourcegraph.containerSecurityContext and .Values.sourcegraph.podSecurityContext, so customers can set the global configs in one place, and if set, override our defaults
• Renamed our default containerSecurityContext and podSecurityContext to defaultContainerSecurityContext and defaultPodSecurityContext, and created empty containerSecurityContext and podSecurityContext keys, so customers who already define overrides for these will continue as-is, without change, and this allows customers to set both the global configs to override our defaults, and override specific configs for specific pods / containers.

Linear issue FEIE-301: Usability: Create instance-wide config for default podSecurityContext and containerSecurityContext

Linked PRs

• fix/resources: Drop unused ports, Services, Role verbs, and settings #1016 deletes the k8s executor's http-debug port 6060 and the executor-<queueName> Service. This PR now deletes them too (4ce480c), so the Service no longer conflicts. executor.Deployment.yaml still conflicts on one line, next to the removed port: keep this PR's sourcegraph.containerSecurityContext line

Checklist

• Follow the manual testing process
• Update changelog
• Update Kubernetes update doc

Test plan

• helm unittest and helm lint pass, for all 4 charts

Tested with helm template commands and compared diffs, using:

• Default values.yaml
• override.yaml files from 3 different customers

[github-actions]

Open the Diff Tour for this PR in Sourcegraph