Manual Changes in Cronjob not detected by Sync Mechanism

[raweber42]

Checklist:

• I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• I've included steps to reproduce the bug.
• I've pasted the output of argocd version.

Describe the bug

Hi!
I am running into an issue where I don't see manual changes to a cronjob reflected in ArgoCD showing the cronjob being out of sync.

I have two examples:

• I had some cronjobs suspended manually and forgot about it. Than I was wondering why they weren't running anymore, because I saw that the application and the cronjob where synced successfully. Only when inspecting the manifest I saw, that suspend = true was set.
• I manually added a command and args field to one cronjob. I assumed that this would result in the cronjob being out of sync (and that I would be able to manually sync that back to the original state). This was not the case, the cronjob stayed in status synced.

PS: I am willing to contribute to resolve this!

To Reproduce

I didn't try on a fresh argo instance, but creating a cronjob like this:

apiVersion: batch/v1
kind: CronJob
  name: test
  namespace: test
spec:
  concurrencyPolicy: Forbid
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - args:
                - >-
                  curl google.com
              command:
                - sh
                - '-c'
              image: alpine/curl:8.6.0
              imagePullPolicy: IfNotPresent
              name: http-request
              resources:
                limits:
                  cpu: 100m
                  memory: 25Mi
                requests:
                  cpu: 100m
                  memory: 25Mi
          restartPolicy: Never
  schedule: 10 * * * *
  successfulJobsHistoryLimit: 1

and then editing the manifest via CLI or ArgoCD UI (especially the suspend, command and args properties) should - according to this bug - lead to ArgoCD still showing synced.

Expected behavior
When manually editing the cronjob, it should change the state to OutOfSync.

Screenshots

Version

{
    "Version": "v3.0.0+e98f483",
    "BuildDate": "2025-05-06T11:25:45Z",
    "GitCommit": "e98f483bfd5781df2592fef1aeed1148f150d9c9",
    "GitTreeState": "clean",
    "GoVersion": "go1.24.1",
    "Compiler": "gc",
    "Platform": "linux/amd64",
    "KustomizeVersion": "v5.6.0 2025-01-14T15:12:17Z",
    "HelmVersion": "v3.17.1+g980d8ac",
    "KubectlVersion": "v0.32.2",
    "JsonnetVersion": "v0.20.0"
}

Logs

Paste any relevant application logs here.

[chengfang]

Are there any log lines showing something is skipped/ignored in application controller log? How is your argocd application configured?

[raweber42]

@chengfang

1. I checked, I couldn't find any
2. We create Applications with Applicationsets. The resulting Application looks like this:

project: test
destination:
  namespace: test
  name: dev
sources:
  - repoURL: https://gitlab.test.io/test/test-agent.git
    path: test
    targetRevision: main
    helm:
      valueFiles:
        - values/test.yaml
      releaseName: test
    ref: customizations
  - repoURL: oci.test.io/charts
    targetRevision: 0.0.8
    helm:
      valueFiles:
        - $customizations/dev/values/test.yaml
    chart: test-agent

[chengfang]

I think in argocd ui, there is a context menu item on the cronjob that allows you to create/suspend/resume a job execution. For your purpose, that seems to be the way to go.

If you change resources imperatively, these changes will just be ignored through auto healing to the git sources. If you change them in git repo sources, they will be picked up by argocd sync.

[raweber42]

If you change resources imperatively, these changes will just be ignored through auto healing to the git sources. If you change them in git repo sources, they will be picked up by argocd sync.

@chengfang how do you know that they are being ignored? Is this documented somehow?

[chengfang]

It's documented https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/#automatic-self-healing . You may want to check if it matches what you're seeing and expecting.

[ChristianCiach]

Since your original (stored in git) document doesn't contain a .spec.suspend attribute, this is expected behavior. This is just how kubectl diff works, as described in this and many similar issues:

• ArgoCD not reporting diff in environment variable configuration #4537

Even self-heal won't help you here.

The command and args fields are curios though. I would totally expect an "out of sync" here, as long as your versioned documents contain these attributes.

You can probably fix the suspend issue by explicity committing suspend: false to your versioned document.

Edit:

I manually added a command and args field to one cronjob.

Yeah, that's the same issue then. kubectl diff only cares about attributes that were set by kubectl apply (which are then stored as the last-applied-configuration annotation (client side apply), or as the fieldManager attributes where argocd set itself as the field manager (server side apply) visible when you uncheck "hide managed fields" when viewing the yaml in the argocd UI).

[raweber42]

ahh, thanks @ChristianCiach, that makes sense!

[raweber42]

Closing this as the behavior is expected:

The properties which I though should be OutOfSync were not configured beforehand. As Argo only considers something OutOfSync if it differs from the configuration file known to it - and I added fields manually which were not configured before, the behavior is expected.