-
Story
-
Resolution: Unresolved
-
Undefined
-
None
-
8
-
False
-
-
False
-
-
-
GitOps Scarlet Sprint 25
Background and Approach (Required)
- See https://github.com/argoproj-labs/argocd-agent/issues/479 for details
Argo CD's job is to deploy K8s resource to K8s clusters. But it needs a way to keep track of which resources it has deployed to the cluster.
Within Argo CD, keeping track of deployed resources is known as 'resource tracking', as described in this doc page; https://argo-cd.readthedocs.io/en/stable/user-guide/resource_tracking/
When a user installs Argo CD, they can choose one of the 3 ways of tracking: annotation (default), annotation+label, and label.
In the annotation case, for example, any K8s resources that Argo CD deploys will have an annotation added to them that looks like this:
annotations:
argocd.argoproj.io/tracking-id: my-app:apps/Deployment:default/my-deployment
However, at present, the Argo CD agent code is (incorrectly) assuming that annotations are used, which is not necessarily the case.
As part of this epic/story, we should add additional support to Argo CD agent to allow it to correctly handle all the resource tracking mechanisms that might be configured.
The fix will likely be in here:
https://github.com/argoproj-labs/argocd-agent/blob/a510ceacc26f405db4bd3abf00027ce578eb9bef/agent/resource.go#L416
Acceptance Criteria (Mandatory)
- Add support for Argo CD resource tracking mechanisms
- Argo CD agent should examine the Argo CD instance and determine which resource tracking mechanism is being used
- It should then use that information in its algorithm to find the correct resource
- Unit/E2E tests to verify functionality
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.