Story (Required)

• As an Operator User or Administrator, I want clear documentation on how to configure the ArgoCD Custom Resource to enable wildcard support, while being directed to the upstream Argo CD documentation for deep-dive behavioral details. This ensures I understand the Operator's specific role (RBAC provisioning) without reading redundant or outdated architectural explanations.

Background and Approach (Required)

• The core logic for processing wildcards lies within the upstream Argo CD ApplicationSet controller. The Operator's role is ensuring the correct permissions (Roles/RoleBindings) exist in the target namespaces so the upstream controller can do its job. To avoid documentation drift and maintenance toil, we will not duplicate the upstream architectural documentation.
• The new documentation will:
  • Focus on the CR: Explain specifically how to configure .spec.applicationSet.sourceNamespaces with patterns (e.g., team-*).
  • Explain the Operator's Action: Clarify that the Operator interprets this config to generate Role and RoleBinding resources in matching namespaces.
  • Reference Upstream: Provide prominent links to the official Argo CD documentation for details on how the ApplicationSet controller utilizes these wildcards.
  • Security Note: Briefly warn that the Operator will grant permissions to any namespace matching the pattern.

Out of Scope

• Detailed explanations of how the ApplicationSet controller watches events (upstream concern).
• Troubleshooting the ApplicationSet controller itself.
• Duplicating "How-to" guides for creating ApplicationSets that already exist in upstream docs.<Defines what is not included in this story.>

Dependencies

• The behavior must exist to be documented

Acceptance Criteria (Mandatory)

• Verify Configuration Focus:
  Given the Operator documentation, when I view the "ApplicationSets in Any Namespace" page, then I see a clear YAML example of the ArgoCD CR using wildcards and the text explicitly states: "The Operator uses this configuration to provision RBAC in matching namespaces."

• Verify Upstream References:
  Given the documentation, when I read about the feature's capabilities, then I find a functioning link to the upstream Argo CD documentation for further reading.

• Verify Scope Boundaries:
  Given the documentation, when I search for details on ApplicationSet generators, then I am referred to upstream docs rather than seeing a partial copy-paste in the Operator docs.

Definition of Done

• Code Complete:
  • Documentation written, reviewed, and approved.

• Tested:
  • Links to upstream documentation have been verified and are reachable.
  • Documentation build passes.

• Documentation:
  • Release notes mention the feature and the reliance on upstream docs for deep dives.

• Build:
  • Documentation changes successfully built and merged.

• Review:
  • Peer-reviewed for clarity and correct linking strategy.

• Deployment:
  • Deployed to the documentation site.