@copilot there is already an annotion with unique value tha tis changed + an helm value: https://github.com/cigales-cloud/argocd-app-of-apps/pull/109/files#diff-ff6c427e587606693535229b02b943930bffd7ed9a5772cbb23316ad7aea4b7eR8-R10

But it does not trigger an argocd sync

@copilot there is already an annotion with unique value tha tis changed + an helm value: https://github.com/cigales-cloud/argocd-app-of-apps/pull/109/files#diff-ff6c427e587606693535229b02b943930bffd7e...

You're right - the current implementation already changes the deployment-id annotation and helm value, but ArgoCD still doesn't sync.

The root cause is that ArgoCD's auto-sync relies on polling Git at intervals (default 3 minutes) and may not reliably detect or act on annotation-only changes, especially if the sync-policy configuration or Application refresh settings don't treat these as significant changes.

The most reliable production-grade solution is to add an explicit ArgoCD refresh trigger annotation that forces a hard refresh on every deployment:

.metadata.annotations["argocd.argoproj.io/refresh"] = "hard"

This annotation explicitly tells ArgoCD to perform a hard refresh of the application when it detects the change, ensuring sync is triggered even when the deployment has identical chart versions and values.

I'll implement this solution by adding the refresh annotation with a timestamp to ensure it changes on every deployment, forcing ArgoCD to detect and act on the change.

@copilot there is already an annotion with unique value tha tis changed + an helm value: https://github.com/cigales-cloud/argocd-app-of-apps/pull/109/files#diff-ff6c427e587606693535229b02b943930bffd7e...

You're right - the current implementation already changes the deployment-id annotation and helm value, but ArgoCD still doesn't sync.

The root cause is that ArgoCD's auto-sync relies on polling Git at intervals (default 3 minutes) and may not reliably detect or act on annotation-only changes, especially if the sync-policy configuration or Application refresh settings don't treat these as significant changes.

The most reliable production-grade solution is to add an explicit ArgoCD refresh trigger annotation that forces a hard refresh on every deployment:

.metadata.annotations["argocd.argoproj.io/refresh"] = "hard"

This annotation explicitly tells ArgoCD to perform a hard refresh of the application when it detects the change, ensuring sync is triggered even when the deployment has identical chart versions and values.

I'll implement this solution by adding the refresh annotation with a timestamp to ensure it changes on every deployment, forcing ArgoCD to detect and act on the change.

@fredleger what do you think about this?

Seems to be a not so good idea: argoproj/argo-cd#19399

@neilime can we setup an adhoc point for this topic. I'm a bit lost

@copilot regarding this issue: argoproj/argo-cd#19399. Do you htink this still the best option to use hard refresh anotationas you mention it?

@copilot regarding this issue: argoproj/argo-cd#19399. Do you htink this still the best option to use hard refresh anotationas you mention it?

You're absolutely right - the ArgoCD discussion shows that using refresh:hard in Git-managed manifests causes an infinite refresh loop. The annotation gets applied from Git, ArgoCD refreshes and removes it, then reapplies it from Git again, creating a cycle.

The better solution is to remove the refresh:hard annotation and rely only on the timestamp annotation. This ensures:

1. Every deployment creates a real Git change (the timestamp updates)
2. ArgoCD detects the Git commit and triggers sync automatically (with automated sync policy enabled)
3. No infinite refresh loop

I'll update the implementation to remove argocd.argoproj.io/refresh: "hard" and keep only the argocd.argoproj.io/refresh-timestamp annotation (or rename it to something clearer like deployment-timestamp).

@copilot adding argocd.argoproj.io/deployment-timestamp will not work, there is already an annotation with unique value "argocd.argoproj.io/deployment-id" that creates a git change, but it does not trigger an ArgoCD sync

@copilot adding argocd.argoproj.io/deployment-timestamp will not work, there is already an annotation with unique value "argocd.argoproj.io/deployment-id" that creates a git change, but it does not tr...

You're right that annotation-only changes don't trigger ArgoCD sync - ArgoCD only syncs on spec changes, not metadata changes.

However, the workflow DOES change the spec: deployment-id is injected into .spec.sources[0].helm.values (not just annotations), which should trigger sync.

The issue might be with the App of Apps pattern:

1. Parent app: Watches child Application CRs in Git
2. Child apps: Need spec.syncPolicy.automated enabled to auto-sync when their spec changes

Questions to diagnose:

• Do the child Applications have spec.syncPolicy.automated enabled?
• Is the parent Application detecting and syncing the child Application CR changes from Git?
• After the workflow commits, does the parent app show "OutOfSync" then sync to update the child Application CR?

If child apps don't have automated sync enabled, the parent will update the Application CR but the child won't deploy the changes automatically - you'd need to manually sync each child app.

@fredleger If you can check copilot question and answer to it please: #228 (comment)

@copilot based on this doc: https://argo-cd.readthedocs.io/en/stable/user-guide/sync-kubectl/, we want to test this strategy:

operation:
  initiatedBy:
    username: ${{ github.actor }}
  info:
  - name: deployment-id
    value: "..." 

@copilot based on this doc: https://argo-cd.readthedocs.io/en/stable/user-guide/sync-kubectl/, we want to test this strategy:

...

This is a much better approach! Adding an operation block directly triggers ArgoCD to sync, rather than relying on it to detect changes.

The operation block would be added to the Application manifest and tells ArgoCD to perform a sync immediately. I'll implement this by adding:

operation:
  initiatedBy:
    username: ${{ github.actor }}
  info:
    - name: deployment-id
      value: ${{ inputs.deployment-id }}
  sync:
    syncStrategy:
      hook: {}

This explicitly instructs ArgoCD to sync the application, solving the issue where Git changes alone weren't triggering sync. I'll update the implementation now.

@copilot handle feedbacks

Feedback addressed in commit f8b1958. Added plugin entry to test template for proper validation of the plugin environment variable update logic.

@copilot handle feedbacks

All feedback addressed in commit 01ce53d:

• Renamed plugin from hk-kustomized-helm to hoverkraft-deployment across all files
• Added conditional check to only update when plugin name is "hoverkraft-deployment"
• Updated README and test files accordingly