[gitops-bootstrap] Trigger immediate sync after Application creation

[sborenst]

Problem

After the ocp4_workload_gitops_bootstrap role creates the ArgoCD Application, the role immediately begins polling for Healthy + Synced status. However, even with automated sync enabled in the Application spec, ArgoCD does not sync immediately on creation — it waits for its next polling interval (default: 3 minutes) before detecting drift and triggering the automated sync.

This causes the Ansible wait task to block for up to 3 minutes before ArgoCD even begins syncing, which adds unnecessary provisioning time.

What this PR does

Adds a single task between Application creation and the health/sync wait loop that patches the Application with an operation block — the same mechanism the ArgoCD UI "Sync" button uses. This triggers an immediate sync rather than waiting for the next poll cycle.

- name: Trigger immediate sync on bootstrap ArgoCD application
  kubernetes.core.k8s:
    api_version: argoproj.io/v1alpha1
    kind: Application
    name: "{{ ocp4_workload_gitops_bootstrap_final_application_name }}"
    namespace: "{{ ocp4_workload_gitops_bootstrap_namespace }}"
    merge_type: merge
    definition:
      operation:
        initiatedBy:
          username: admin
        sync:
          syncStrategy:
            hook: {}

Notes

• This may only affect certain environments or ArgoCD configurations where the polling interval is long or the Application creation → first sync gap is noticeable
• It is safe to apply generally: if the Application is already syncing, the operation is a no-op
• No variables or defaults were changed — this is purely additive

Testing

Observed in a provisioning environment where bootstrap-tenant-{{ guid }} consistently sat in OutOfSync status for 2–3 minutes after creation before the automated sync fired. With this change, sync begins within seconds of the Application being created.

[juliaaano]

Since I created this role myself, I’ll go ahead and jump in.

I didn’t know about this new capability built in directly in the Application definition. Really nice!

One question though: would adding that directly to the Kind: Application at the time it is created work?

This avoids merging the object and makes it a bit cleaner, but not sure if it would work as expected as I haven’t tested this.

So basically adding this:

    definition:
      operation:
        initiatedBy:
          username: admin
        sync:
          syncStrategy:
            hook: {}

Directly here: https://github.com/agnosticd/core_workloads/blob/main/roles/ocp4_workload_gitops_bootstrap/templates/application.yaml.j2