feat(ui): populate parameter dropdowns dynamically from Kubernetes resources (dynamic `enum`)

[lwarratz]

Summary

What change needs making?

Today, enum on a workflow parameter is a static list baked into the manifest:

arguments:
  parameters:
    - name: target-namespace
      value: "namespaceA"
      enum: ["namespaceA", "namespaceB", "namespaceC"]

I'd like a way to declare that the list of allowed values should be resolved from live
Kubernetes resources when the Submit form is rendered, so operators pick from what
actually exists on the cluster instead of a hand-maintained list.

Strawman API — a new enumFrom alongside the existing enum:

arguments:
  parameters:
    - name: target-namespace
      enumFrom:
        resource:
          apiVersion: v1
          kind: Namespace
          jsonPath: "{.metadata.name}"          # value to use for each item
          labelSelector: "appspace=test"   # optional filter

    - name: target-deployment
      enumFrom:
        resource:
          apiVersion: apps/v1
          kind: Deployment
          namespace: "{{workflow.parameters.target-namespace}}"   # cascading (see below)
          jsonPath: "{.metadata.name}"

Design notes / things I'd expect to be contentious:

• RBAC must be the submitting user's, not the controller's. Resolution should happen in
  the Argo Server, using the caller's credentials (SSO token / SA), so the dropdown can
  never disclose the existence of resources the user isn't allowed to see. This is the part
  I'd most want maintainer input on.
• UI affordance, not a security control. The resolved list should not be treated as
  server-side validation of submitted values — a user who can submit a workflow can already
  supply arbitrary parameter values. It's about discoverability and typo-avoidance.
• Graceful degradation. If resolution fails (RBAC denied, CRD absent, API timeout), the
  field should fall back to a free-text input with a visible warning rather than blocking
  submission.
• Load. Resolution only on form render, with a short server-side cache and a cap on
  returned items, to avoid hammering the API server for large clusters.
• Cascading dropdowns (namespace → deployments in that namespace) are the real prize
  but clearly harder, since the form must re-resolve when an upstream field changes. Happy
  for that to be a phase 2 — even non-cascading, cluster-scoped lists (namespaces, cluster
  workflow templates, storage classes) would be a big win on their own.

Use Cases

When would you use this?

We run a ClusterWorkflowTemplate that restarts a specific workload at a scheduled
date/time, with parameters for target-namespace, target-kind and target-name.
Operators submit it from the UI.

The names of deployments and namespaces are exactly the kind of thing that changes
constantly, so today we have two bad options:

1. Hardcode the enum — we do this in another template, and it carries this comment:

   # Namespace → App mapping (Argo UI does not support
   # conditional dropdowns, so all apps are listed.
   # Pick the namespace that matches the chosen app.)

   The list goes stale the moment someone adds a service, and it can't express
   "these deployments belong to that namespace", so the UI offers invalid combinations.

2. Leave it as free text — which is what we ended up doing, and it means typos are only
   caught once the workflow runs. For a scheduled workflow that's genuinely painful: a
   mistyped deployment name sits in a suspended node all night and fails at 03:30, having
   restarted nothing. We've had to add a pre-flight validation step whose entire job is to
   fail fast and print the valid options into the logs — a workaround for a dropdown we
   can't build.

Other cases that would benefit:

• Picking a PVC / Secret / ConfigMap to operate on.
• Picking a target ClusterWorkflowTemplate or WorkflowTemplate for a dispatcher workflow.
• Any self-service / operator-facing workflow where the audience is not the person who
  wrote the manifest, which is where the UI's Submit form is most valuable.

---

Message from the maintainers:

Love this feature request? Give it a 👍. We prioritise the proposals with the most 👍.