Story (Required)

• As a Cluster Administrator, I want the Operator to automatically detect the creation of new namespaces that match an active wildcard pattern, so that the ApplicationSet capability is available immediately without requiring an Operator restart or manual reconciliation.

Background and Approach (Required)

• While https://issues.redhat.com/browse/GITOPS-8278  handles the logic, the Operator needs to know when to trigger that logic. If a user creates a new namespace team-b, the Operator must react. 
• The technical approach involves:
  • Configuring the Controller-Runtime manager to Watch Namespace resources.
  • Adding a Predicate (event filter) that checks if a newly created Namespace name matches any of the patterns currently defined in the ArgoCD CR.
  • If a match is found, enqueue a reconciliation request for the ArgoCD object.

Out of Scope

• The actual creation of RoleBindings (handled in https://issues.redhat.com/browse/GITOPS-8278 ). This story is strictly about the Event Watcher and Trigger mechanism.

Dependencies

• https://issues.redhat.com/browse/GITOPS-8278  (The reconciliation logic must exist to be triggered)

Acceptance Criteria (Mandatory)

• Given the Operator is running with a configured pattern dev-*, when I create a new namespace named dev-feature-1, then the Operator detects the Namespace Create event. And the Operator triggers a reconciliation of the ArgoCD CR. And the RBAC resources appear in dev-feature-1 within seconds.

Given the Operator is running, when I create a namespace production-v1 that does not match the pattern dev-*, then the Operator ignores the event and does not trigger a reconciliation.

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.