`helm template`, and by extension skaffold render's direct use of it, has the behavior that the `namespace` parameter is not applied to resources managed by the helm chart. Can/
Helm's behavior means that `helm install ...` and `helm template ... | kubectl ...` have different behavior unless a user also adds the namespace argument to kubectl. For skaffold users, this affects gitops-style workflows built on `skaffold render`, with the difference being that a single skaffold configuration likely manages resources in more than one namespace.
There are many issues about this in helm land, such as
https://github.com/helm/helm/issues/3553, but the short version is that helm is not changing it. Helm leaves it up to deployment tools to apply a namespace to template output for
philosophical and performance reasons. Helm has also established a "best practice" that explicitly discourages chart authors from parameterizing their namespace like other chart parameters. In practice a variety of post-processing helper tools and scripts are floating around for helm users to work around this.
In Skaffold, it's normal to have something like:
some_root/skaffold.yaml:
[...]
requires:
- path: ./skaffold-module-using-a-helm-chart
- path: ./skaffold-module-using-another-helm-chart
With `skaffold render` on the root file, there's no way to set the two helm charts to different namespaces.
`skaffold render` could be modified to read *.helm.releases.namespace and insert it into the helm template output's namespace-compatible resource metadata alongside other existing post-processing. Viewed as a bug fix, this change would be backward compatible except in pathological cases, and it might clean up the behavior in
https://github.com/GoogleContainerTools/skaffold/issues/7101. (It is a good feature of `skaffold render` that its output can be consumed by standard tools other than `skaffold apply`). Viewed as a skaffold feature that streamlines a common task for helm gitops users, it could also be justifiably hidden behind a configuration variable.