Applicationset targetRevision issue for using split repos with pull request generator

[nia-potato]

hi ive been struggling to get a multi repo setup for the pull request generator in a appset. Lets say:

• repo1: is where the user requests a argocd cluster provisioning flow in their MR/PR.
• repo2: is where all the deployments + argocd configurations are stored.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: mr-cluster-argocd
  namespace: argocd
spec:
  generators:
    - pullRequest:
        gitlab:
          project: "group/repo1"
          api: https://gitlab.domain.com/
          tokenRef:
            secretName: gitlab-token
            key: token
          labels:
          - create-cluster
          pullRequestState: opened
          insecure: true
        requeueAfterSeconds: 30
        template:
          metadata: {}
          spec:
            destination: {}
            project: ''
  template:
    metadata:
      name: t-{{number}}-cluster-deploy
    spec:
      destination:
        name: in-cluster
        namespace: t-demo
      project: default
      source:
        kustomize:
          namePrefix: t-{{number}}-
          patches:
            - patch: |-
                - op: add
                  path: /metadata/labels/targetRevision
                  value: '{{head_sha}}'
              target:
                kind: XKind
                name: cluster
        path: pr-environments/kustomize/
        repoURL: [email protected]:group/repo2.git
        targetRevision: '{{head_sha}}'
      syncPolicy:
        automated:
          selfHeal: true

so basically the pull request generator will monitor PRs in repo1, while the manifests it will deploy live in repo2. when i tried to do this i got

Failed to load target state: failed to generate manifest for source 1 of 1: rpc error: code = Unknown desc = failed to initialize repository resources: rpc error: code = Internal desc = Failed to checkout revision d6d1b99b...

which im assuming is because it expected that head sha in repo2 as well via targetRevision, not just in repo1.

So knowing this issue, and unable to control what the users branch name creation in repo1, how would one fill repo2's targetRevision so that the cluster manifest gets deployed?

i would really like to avoid having a separate job somewhere where its only function is just creating branch clones in repo2 whenever repo1 has a new branch.

or should i be using something else?

thanks