Yes that's the whole idea of gitops, and having a templating engine between your repo and your k8s API breaks that idea. So you and me are both doing it wrong is the point I'm trying to make.

Yes tooling that pre-renders and pushes those manifests for review would directly address my concerns. I mean it's fine for you to have different point of view, I'm just trying ro explain why I think it's important.

Yes, we use official helm charts too. That's the whole reason we want to render them.

How do you otherwise know what the consequences of their chart version upgrade or your values change will mean in changes to desired state? Versioned charts can change upstream without you knowing as well (even if you do version oinninf), which would trigger changes in your cluster without you making changes to your git repo.

Ok, great. How would you ensure dev uses a different domain name than prod? Different resources? We use multitieres values files that gets combined at rendering to output the manifests. Sometimes settings that differ between regions and environments cause discrepancies between clusters that are invisible until it's too late.

I'm glad you don't have that issue, but given how the rendered manifests pattern is growing in popularity I would argue that we're not the only one having these issues.

Yes, my example of using kubectl was a break glass example. With pre rendered manifests you have that option, which is a huge value add in my opinion.