Description of Problem

• Customer would like to use both Helm and ArgoCD to manage their app sets and deployments. When using ArgoCD and Kustomize, Argo recognises those github changes quickly and the synchronisation works. The same cannot be said for Argo and Helm. When making changes to a values file or even to the version of the chart Argo seems to ignore it despite forced sync’s and hard refreshes.

The other issue with using Helm and ArgoCD is that the helm values are displayed as parameters in the Argo web UI and I can change them. This completely bypasses the gitops idea.

Additional Info

• Ultimately we want a simple way for the customer to deploy applications, using a common base with a way to inject variance for each application
• Some of the issues I have seen upstream that describe similar patterns are as below:[ |https://github.com/argoproj/argo-cd/issues/9214]
• https://github.com/argoproj/argo-cd/issues/9214 https://github.com/argoproj/argo-cd/issues/2967
• https://github.com/argoproj/argo-cd/issues/12366

Problem Reproduction

• <How do we reproduce the problem?>

Reproducibility

• <Always/Intermittent/Only Once>

Prerequisites/Environment

• <OpenShift, managed service (e.g., ROSA, ARO), operators, layered product, and other software versions, build details>

Steps to Reproduce

• ...

Expected Results

• ...

Actual Results

• ...

Problem Analysis

• <Completed by engineering team as part of the triage/refinement process>

Root Cause

• <What is the root cause of the problem? Or, why is it not a bug?>

Workaround (If Possible)

• <Are there any workarounds we can provide to the customers?>

Fix Approaches

• <If we decide to fix this bug, how will we do it?>

Acceptance Criteria

• ...

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.