Mike Bryant

Might switching to using [server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) be an option here? This would let the k8s apiserver handle the three-way diff / updates etc, and allow other controllers/webhooks to touch fields...

But it does? This is a direct replacement for kubectl client-side apply, which does a three way diff. The live object (A) is stored in the `.metadata`, `.spec` etc. The...

This is exactly what server-side apply will do for you > The labels and annotations previously configured in the custom resource This information is stored in `metadata.managedFields`. For each field...

Application yaml for one exhibiting the problem: [app.txt](https://github.com/argoproj/argo-cd/files/12394374/app.txt)

Found these issues that look relevant: - https://github.com/kubernetes/kubernetes/issues/58017 - https://github.com/helm/helm/pull/3459 `persistAppStatus` uses `CreateTwoWayMergePatch` uses [strategicpatch](https://github.com/argoproj/gitops-engine/blob/187312fe86ed627b1cf4147c13dccf9ff331424b/pkg/diff/diff.go#L813). Seems like this might not be happy with the unstructured content in `valuesObject`?

@crenshaw-dev Is there anything more we need to do here, or can this proposal be accepted?

Also see https://github.com/argoproj/argo-cd/issues/12208

I also raised this here: https://github.com/semantic-release/gitlab/issues/152 My thinking there is - whatever the default branch that someone has set in the Gitlab configuration, semantic-release should support it, when being run...

Also the current diff behaviour only works for changes to the chart, it doesn't work for changes to `Application.spec.source.helm.values`

We just hit this too - relied on the docs and have only found this after debugging it not working :(