Add optional name reference to Source object

[agaudreault]

Summary

With the support of multi-source, it is only possible to reference a source by it's position in the list. If people build automation around sources and the order change, it could break the users workflow.

Adding an optional name parameter to the source object would allow to build safer automation and facilita the identification of sources in the UI.

Motivation

When using the CLI with multi-source application.

Before

argocd app manifests test --revisions d7927a27b4533926b7d86b5f249cd9ebe7625e90 --revisions 53e28ff20cc530b9ada2173fbbd64d48338583ba --source-positions 1 --source-positions 2

After

argocd app manifests test --revisions d7927a27b4533926b7d86b5f249cd9ebe7625e90 --revisions 53e28ff20cc530b9ada2173fbbd64d48338583ba --source-names gitops-test --source-names base

Proposal

• Add name parameter to source
• Add --source-name parameter to the CLI. Do not allow to specify both named and position parameters.
• If ref is set for a source and name is not set, evaluate if the name could default the the ref value. (similar to how releaseName has a default of the applicationName if not specified)
• Add in the multi-source UI

spec:
  destination:
    name: dev
    namespace: dev
  project: tests
  sources:
  - name: base            # <--- can be referenced as "base", or position 1
    chart: hello-world
    helm:
      valueFiles:
      - $gitops-test/services/multi-source-ref/values.yaml
    path: whatever
    repoURL: https://helm.github.io/examples
    targetRevision: 0.1.0
  - path: services/multi-source-with-ref
    ref: gitops-test       # <--- can be referenced as "gitops-test", or position 2
    repoURL: https://github.com/agaudreault/gitops-tests
    targetRevision: test-sync

Related work

#17425
#17650
#17589
#17275

[crenshaw-dev]

How would you feel about using ref, since that's already in the spec?

imo, in apiVersion v1 it should probably be required and a merge key.

[ishitasequeira]

If we introduce name field, I do not think we can fall-back on ref field as the values in name for field might match with value ofref` field in another source, in turn introducing bunch of issues.

I agree with @crenshaw-dev, I think we can re-use ref instead of introducing name as a new field.

[agaudreault]

I felt like ref currently have some restriction and cannot be specified for non-git source like helm and so on. So I was hesitant to mix concepts and reuse the parameter for 2 different purposes.

Maybe name should not default to ref. I was thinking about the display in the UI, but it does increase complexity for not much if it is defaulted in the backend. And without default, if users specify the same value for name and ref of different source, they are kind of responsible for their own confusion 😅