Helm chart 'kind' reference confuses ArgoCD

[kenlasko]

What version of descheduler are you using?

descheduler version: 0.31.0

Does this issue reproduce with the latest release?
Yes

Which descheduler CLI options are you using?
N/A

Please provide a copy of your descheduler policy config file
Via values.yaml:

# kind: Deployment
schedule: "30 */2 * * *"  # Every hour at 30 min past
priorityClassName: high-priority
deschedulerPolicy:
  nodeSelector: "storage=longhorn"
  strategies:
    RemoveDuplicates:
      enabled: true
    RemovePodsHavingTooManyRestarts:
      enabled: true
      params:
        podsHavingTooManyRestarts:
          podRestartThreshold: 10
          includingInitContainers: true
    RemovePodsViolatingNodeTaints:
      enabled: true
    RemovePodsViolatingNodeAffinity:
      enabled: true
      params:
        nodeAffinityType:
        - requiredDuringSchedulingIgnoredDuringExecution
    RemovePodsViolatingInterPodAntiAffinity:
      enabled: true 
    RemovePodsViolatingTopologySpreadConstraint:
      enabled: false
      params:
        includeSoftConstraints: false
    LowNodeUtilization:
      enabled: true 
      params:
        priorityThreshold:
          name: "medium-priority"
        nodeResourceUtilizationThresholds:
          thresholds:
            cpu: 100
            memory: 100
            pods: 20
          targetThresholds:
            cpu: 100
            memory: 100
            pods: 33

What k8s version are you using (kubectl version)?
1.31.2

What did you do?
When attempting to change from using CronJob to Deployment for Descheduler, the kind: Deployment reference in the values.yaml makes ArgoCD think it is a manifest and throws the error: groupVersion shouldn't be empty

Simplest fix would be to change the kind reference to something else to avoid the confusion. I suggest something like appKind or something similar.

[echozio]

I would think this would be better dealt with by either putting values.yaml somewhere where ArgoCD doesn't look for manifests to deploy or by setting an include or exclude pattern on the responsible application's directory source.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale