Description of problem:

Reported by rhn-support-klapagna in Slack.

I'm trying to put an application on a managed cluster that uses the cluster name as Helm parameter. Unfortunately ACM does not transport the helm: dict to the managed cluster. This is part of my ApplicationSet - see the valuesObject:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
...
  template:
    metadata:
      annotations:
        apps.open-cluster-management.io/ocm-managed-cluster: '{{name}}'
        apps.open-cluster-management.io/ocm-managed-cluster-app-namespace: openshift-gitops
        argocd.argoproj.io/skip-reconcile: 'true'
      labels:
        apps.open-cluster-management.io/pull-to-ocm-managed-cluster: 'true'
        velero.io/exclude-from-backup: 'true'
      name: <something>-{{name}}
    spec:
      destination:
        namespace: <ns>
        server: '{{server}}'
      project: default
      source:
        helm:
          valuesObject:
            clusterName: '{{name}}'
        path: <path>
        repoURL: <url>
        targetRevision: main
      syncPolicy:
... 

Now, the Application object on the ACM hub cluster has the valuesObject properly defined. But in the Application on the managed cluster is missing that dict:

apiVersion: argoproj.io/v1alpha1
kind: Application
...
spec:
  destination:
    namespace: <ns>
    server: 'https://kubernetes.default.svc'
  project: default
  source:
    path: <path>
    repoURL: <url>
    targetRevision: main
  syncPolicy:
... 

I can see, that it's already missing in the respective ManifestWork on the hub cluster:

apiVersion: work.open-cluster-management.io/v1
kind: ManifestWork
...
          source:
            helm: {}
            path: <path>
            repoURL: <url>
            targetRevision: main
... 

So it looks like whatever creates this ManifestWork ditches this information.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

See description for more details.

1. Use ArgoCD Pull Model Integration to an Application on the hub cluster with spec.source.helm populated.
2. The ManifestWork that is wrapping the Application does not include the spec.source.helm in it's payload
3. The Application is propagated to the managed cluster without the spec.source.helm field.

Actual results:

The ArgoCD Application is propagated to the managed cluster without the spec.source.helm field which causes it to either fail or misbehave.

Expected results:

The ManifestWork should contain the spec.source.helm field in it's Application Payload so the Application is propagated to the managedcluster with that field as well.

Additional info:

Initial triage copied from the Slack thread:

In summary:

The hub's dormant Application has the right spec

The ManifestWork created by the propagation controller does not have the spec

As a result of the above the Application in the managed cluster does not have the correct spec

We DO copy the entire spec over to the ManifestWork. The code is here. As of now, I don't see any manipulation under the source so the dormant application spec.source should just get wrapped by ManifestWork.
The problem is most likely due to the fact that the ArgoCD API is hard to consume because they mix their controllers and dependency in the same repo. As a result of that, we copied their API out separately so we can easily control it. It seems like the ACM copied ArgoCD API is not up to date with the GitOps Operator ArgoCD API so I am assuming this new helm field is missing.