volker.raschekandCopilot
377306b418
`podSecurityContext` and `containerSecurityContext` are both Deployment-scoped: the former is rendered into `spec.template.spec.securityContext`, the latter into the securityContext of the Gitea container and the chart-managed init containers. Keeping them at the top level hid that pod/container distinction behind a naming convention and separated them from the other pod- and container-scoped settings that already live under `deployment` and `deployment.gitea`. `podSecurityContext` therefore becomes `deployment.securityContext` and `containerSecurityContext` becomes `deployment.gitea.securityContext`, which makes the scope obvious from the values path alone and continues the consolidation started with `deployment.gitea.env`, `deployment.gitea.resources` and `deployment.gitea.image`. The template helpers keep their argument-based signatures, because `gitea.containerSecurityContext` is also used by the Helm test pod and is not bound to a single values path. Both removed keys are covered by the deprecation check so that a silently dropped security context cannot lead to containers unexpectedly running as root or without the configured capability set. BREAKING CHANGE: `podSecurityContext` and `containerSecurityContext` no longer exist. Use `deployment.securityContext` and `deployment.gitea.securityContext` instead. Installations that still set the old keys will fail to render unless `checkDeprecation` is set to `false`. Co-authored-by: Copilot <copilot@github.com>