Story (Required)

• As a Cluster Administrator, I want the ArgoCD Operator to accept and process wildcard patterns (e.g., team-*) in the .spec.applicationSet.sourceNamespaces field, so that the Operator automatically provisions the necessary RBAC permissions in all existing namespaces that match the pattern.

Background and Approach (Required)

• Currently, the Operator requires a strict, static list of namespaces. This creates toil when managing large numbers of dynamic environments.
• The technical approach involves:

• • Updating the ArgoCD reconciliation loop to parse the strings in sourceNamespaces.
  • Implementing a glob/pattern matching function (leveraging existing logic from apps-in-any-namespace).
  • Querying the cluster for the list of all namespaces.
  • Filtering that list against the configured patterns.
  • Ensuring the argocd-applicationset-controller ServiceAccount has a Role and RoleBinding created in every matching namespace.

Out of Scope

• This story covers the reconciliation of existing namespaces during the standard loop. It does not explicitly cover the Event Watcher optimization for newly created namespaces (handled in the next story), though the logic implemented here is the prerequisite for that.

Dependencies

• none

Acceptance Criteria (Mandatory)

• Given an existing ArgoCD CR, When I update .spec.applicationSet.sourceNamespaces to include team-*, Then the Operator identifies all existing namespaces starting with "team-". And the Operator creates a Role and RoleBinding in those namespaces targeting the ApplicationSet controller ServiceAccount.

• Given an ArgoCD CR with a wildcard configuration, When I remove the wildcard pattern from the CR, Then the Operator deletes the RBAC resources from the namespaces that no longer match any configured pattern.

• Given the implementation, When I run the unit tests, Then the glob matching logic passes for standard cases (, prefix-, *-suffix).

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.