Epic Goal

Currently, Argo CD supports running built-in resource actions from the UI/CLI. Users can also create custom actions by adding the configuration in the argocd-cm configmap. More about resource actions: https://argo-cd.readthedocs.io/en/stable/operator-manual/resource_actions/

The Argo CD server needs access to the cluster's k8s API to run these actions. However, with argocd-agent, the server will not have direct access to the resources on the workload cluster. The goal of this epic is to configure the argocd-agent to support running both built-in and custom resource actions. We could rely on the existing resource proxy implementation to intercept the calls to run actions from the server. The resource proxy design is described in this doc.

 High-level overview 

1. The user runs the actions via Argo CD UI/CLI on the control-plane
2. Argo CD server makes an API call to the proxy to fetch the live resource
3. The proxy talks to the correct agent and returns the required resource from the workload cluster
4. Argo CD server will read the action configurations from the argocd-cm and execute the action on the resource.
5. The proxy should send the updated/new resource back to the correct workload cluster.

Acceptance Criteria

• Users should be able to list/run both built-in and custom resource actions when using argocd-agent
• Unit tests and e2e tests to verify the behavior
• Required PRs are reviewed and merged in the argocd-agent repository
• All the child stories are marked as Done

Definition of Ready

• The epic has been broken down into stories. Stories have been scoped.
• The epic has been stack ranked.

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Integration tests have been completed.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested on OpenShift either upstream or downstream on a local build
• Documentation:
  • User documentation or release notes have been written.
• Build:
  • Code has been successfully built and integrated into the main repository / project
• 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
• Acceptance:
  • Product Manager or stakeholder has reviewed and accepted the work.