ArgoCD UI shows incorrect values when using ArgoCD + Helm for deployment
Describe the bug
When deploying applications using Helm + ArgoCD and passing Helm values from ArgoCD manifest file to override the default helm values, the PARAMETERS section in the PARAMETERS tab still shows the default Helm chart values.
The Application does get created with helm values that are passed from the ArgoCD manifest file, so we are good there. But, would like to understand if this is the default behavior of ArgoCD when put together with Helm or it should show the values that are sent from ArgoCD manifest file.
To Reproduce Override default Helm values from ArgoCD manifest files using:
source:
helm:
values: |
values...
Expected behavior The PARAMETERS section in the PARAMETERS tab should show values that were passed from the ARgoCD manifest files. If not, the UI should indicate saying that it is default helm values.
Screenshots

Version
v2.3.3+
This could be a duplicate of https://github.com/argoproj/argo-cd/issues/9175
@guitmz rightly pointed out that this has not been fixed.
The fix was for showing values from "Values Files," not from "Values." Showing the "Values" overrides in "Parameters" is still tbd.
Any updates on this?
Does ArgoCD auto pick a file called "values.yaml" if there?
@CzapBran Yes, but I believe this is how helm behaves, not Argo. When you specify values in the UI, they end up in a randomly generated file name so they do not override the values.yaml inside the chart.
see: https://github.com/argoproj/argo-cd/blob/master/reposerver/repository/repository.go#L858-L932 for reference (https://github.com/argoproj/argo-cd/issues/11529)
@alexef Yup, you're right, tested it out without any file named "values.yaml" and it works as expected. I'll removed the comment as it's not relevant
@alexef @iampranabroy Is this PR still relevant?
Hi, Is this still an issue?
I'm using the .argocd-source-<appName>.yaml file to override the image.tag param. But seeing the default latest tag in ArgoCD Parameters screen
ArgoCD version v2.8.4
Yeah it's still an issue, I'm seeing it with v2.10.7.
Spent about ~1 hour assessing what's wrong with ApplicationSet and values... 🤦🏻
v2.12.2+560953c
spent a day.. still happening in v.2.11, helm values in mulisource never overrides helm parameters
We've just starting hitting this issue in v2.11 and v2.12.5 when testing locally to see if upgrading would resolve. We switched from single source to multi source and that was when the issue started.
We're less concerned about the values being wrong in the UI (although that is a problem) and more concerned about the fact that they are wrong in the Argo Notification messages, as we rely on these for progressing builds through environments (image tag is set as a value so now the default <nil> shows in the notification message).
Spent 4+ hours trying to understand why my values were not taken correctly. Having problems with single source too.
The issue still exist with version 3.0. The UI takes the default values.
Hi. Any plans to make this more intuitive and/or fix this? Thx
This issue is quite frustrating - I attempted your advice of switching to parameters, however we are looking to migrate from native helm + values to parameters, and so I had to write a script to convert my yaml to dot-notation dynamically, and even then the terraform provider baulked at multi-line strings in the resultant values, which I have yet to solve. I would very much appreciate this being fixed as opposed to implementing a multitude of hacks myself or maintaining two parameter systems as I migrate.
issue still thre in 3.0.2 it is making error analysis quite challenging
This issue is quite frustrating - I attempted your advice of switching to parameters, however we are looking to migrate from native helm + values to parameters, and so I had to write a script to convert my yaml to dot-notation dynamically, and even then the terraform provider baulked at multi-line strings in the resultant values, which I have yet to solve. I would very much appreciate this being fixed as opposed to implementing a multitude of hacks myself or maintaining two parameter systems as I migrate.
I ended up with a partially written script that fixed most of the issues - this was caused by the helm template command baulking at unescaped characters when using --set, which doesn't happen when you use values files as it doesn't use this argument. Here is my WIP code, it needs some work especially for lists, but I have used it on a cluster with ~30 applications, and with autosync disabled it returned with no planned changes
#!/usr/bin/env python3
"""
Flatten nested YAML/JSON structure to dot notation.
Reads JSON query from stdin (Terraform external data source format).
Outputs flattened JSON to stdout.
"""
import json
import sys
def escape_helm_value(v):
"""
Escape a value for use in Helm's --set parameter.
Based on Helm's escaping requirements for --set command line arguments.
Helm interprets bare values as typed (int, bool, etc), so we force booleans
and numbers to strings by wrapping them in escaped quotes to prevent type
inference issues in Helm templates.
Args:
v: Value to escape
Returns:
Properly escaped string value for Helm --set
"""
if isinstance(v, list):
# Lists are converted to comma-separated values with proper escaping
# Each element needs to be escaped recursively
if len(v) > 0:
escaped_items = [escape_helm_value(item).replace(',', '\\,') for item in v]
return '{' + ','.join(escaped_items) + '}'
else:
return ''
else:
# Fallback: convert to string and escape
escaped = str(v)
escaped = escaped.replace('\\', '\\\\')
escaped = escaped.replace('{', '\\{')
escaped = escaped.replace('}', '\\}')
return escaped
def flatten_dict(d, parent_key='', sep='.'):
"""
Flatten a nested dictionary to dot notation.
Args:
d: Dictionary to flatten
parent_key: Parent key prefix
sep: Separator for keys (default '.')
Returns:
Flattened dictionary with dot-notation keys and properly escaped values
"""
items = []
for k, v in d.items():
new_key = f"{parent_key}{sep}{k}" if parent_key else k
if isinstance(v, dict):
# Recursively flatten nested dictionaries
items.extend(flatten_dict(v, new_key, sep=sep).items())
elif v is None:
# Skip null values
continue
else:
# Escape the value according to Helm's requirements
items.append((new_key, escape_helm_value(v)))
return dict(items)
def main():
"""Read JSON query from stdin, flatten the input, and output to stdout."""
try:
# Read query from stdin (Terraform external data source format)
query = json.loads(sys.stdin.read())
# The input data is in the "input" key as a JSON string
input_json = query.get("input", "{}")
data = json.loads(input_json)
# Flatten the structure
flattened = flatten_dict(data)
# Terraform external data source requires all values to be strings
# and the output must have a "flattened" key containing the result
output = {
"flattened": json.dumps(flattened)
}
# Output as JSON
print(json.dumps(output))
sys.exit(0)
except json.JSONDecodeError as e:
# Return error in expected format
print(json.dumps({"error": f"Invalid JSON input: {e}"}), file=sys.stderr)
sys.exit(1)
except Exception as e:
# Return error in expected format
print(json.dumps({"error": f"Error: {e}"}), file=sys.stderr)
sys.exit(1)
if __name__ == "__main__":
main()
We are using this as a terraform data source and adding an argocd_application to our cluster as opposed to deploying via helm with terraform. Eventually we are looking to adopt a gitops approach, but this is a step on that journey. Arguably this should be fixed elsewhere, but where is the question - the bug is actually with the helm command, so should it be fixed in helm, in argocd itself, or the terraform provider? Almost certainly not the latter, as that would not fix other use cases probably not in helm, and in argo seems a little hacky too 🤷
IMO, even if argo does not read values in to parameters in the UI as a full fix, it should should at least be updated so that if parameters are provided, they are escaped to pass to the helm templating command.