Support ignoreDifferences as a resource annotation

[TimJones]

Summary

It would be great if the Application spec ignoreDifferences could be supported at the individual resource level, perhaps as an annotation.

Motivation

I am converting my set up use an ApplicationSets whenever possible to reduce boilerplate. A few Applications require specific ignoreDifferences config. In my case, one app has a ConfigMap resource, and another app updates it with dynamic configuration settings.

Proposal

Ideally similarly to syncOptions can be applied to individual resources via the argocd.argoproj.io/sync-options annotation. So there could be an argocd.argoproj.io/ignore-differences annotation.
Since the annotation is applied to a specific resource, there is no need to define the kubernetes API group in the annotation. It could be further simplified by (initially) only supporting a single jsonPointers type.

i.e.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-dynamic-config
  annotations:
    argocd.argoproj.io/ignore-differences: /data/config
data:
  config: ''

or it could support being parsed out as a yaml/json object similar to the existing ignoreDifferences spec.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-dynamic-config
  annotations:
    argocd.argoproj.io/ignore-differences: |-
      jsonPointers:
      - /data/config
data:
  config: ''

[thesuperzapper]

@pasha-codefresh @blakepettersson this feature would be amazing, as it would allow for many more "escape hatches" without needing to update the Application itself.

[thesuperzapper]

This is also related to the request of having the ability for a specific resource to be "ignored" (not updated during a sync) if it has a specific annotation (e.g. argocd.argoproj.io/sync-options: Ignore=true)

Here is the issue for that request:

#7975

[PurseChicken]

I also have a need for this. Being able to do this on a specific resource via annotation is critical.

[Goose29]

This would be a awesome addition, eliminating the need to manage a large list in the Application CRD.

[andrii-korotkov-verkada]

In my case, one app has a ConfigMap resource, and another app updates it with dynamic configuration settings.

This kinda goes against the idea of resource being owned by an application and using manifests in a repo to control values.

[andrii-korotkov-verkada]

If it's still necessary, I'd prefer to use application-level annotations, since they are already available and support even per-resource config, see https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/#application-level-configuration. Lack of a centralized place to see what differences are ignored can make it harder to do updates, e.g. if some annotation needs to be removed, people may not find it and revisit if it's still needed. Please, let me know if you are not convinced by these arguments and why.

[PurseChicken]

In my case, my applications are all derived from application sets. My fear is that if that application-level annotation is included as part of the application set it will apply to all applications derived from them which is not desired at all.

I have a specific manifest that I apply as part of an application (specifically tailscale-operator) which has a field that gets overwritten dynamically by the operator. This causes the application to show as out of sync in Argo. If I had a way to add an annotation to that specific manifest to basically ignore the specific field of that manifest, then my issue would be resolved.

[andrii-korotkov-verkada]

You can try solving this with generator templates https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Template/#generator-templates. Lmk if that works for you.

[PurseChicken]

I use generator templates, but the templates are the source of every application created by the application set. So as I mentioned prior, this would then apply to all applications which would not be desired.

Unless there is a way to apply it to a single app manifest via the template. I could totally be missing something here.

[andrii-korotkov-verkada]

I think you can have multiple generators - one for one app you need overrides and one for everything else. Let me know if it's not actually possible.

[PurseChicken]

That would then mean that I would have to break up the application set into multiple scopes excluding the specific sub folder of the deployment repository and then have an additional one specific to that repository folder only. I guess thats technically possible, but that complicates the app of apps pattern.

It would certainly be tremendously easier to just add an annotation to the specific manifest that is applied.