'hard refresh' buggy, chart including chart dependencies 0.0.x

[lknite]

Checklist:

• I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• I've included steps to reproduce the bug.
• I've pasted the output of argocd version.

Describe the bug

I'm developing an app and using argocd for deployment.

I have an over-all chart which includes several charts (one for each of my microservices), using '0.0.x' so the latest helm chart is deployed automatically. It seemed to work for awhile, but doesn't work anymore.

I think there may be caching issues. I try 'hard refresh' which has helped in the past but doesn't seem to work at all now.

To Reproduce

1. deploy the 'list' helm chart using version: '0.0.x' so always using the latest version of 'list' (this includes the other helm charts as dependencies, using 0.0.x for each one)
2. push a new helm chart of one of the dependencies (with an increased version number) (expect new dependency to deploy, but it doesn't)

Whenever I rebuild the over-all helm chart 'list' or one of the microservices like 'api-blocks' the "version" patch number is increased by one. helm charts are stored in a local harbor instance, and is using oci (if that matters).

Here's the overall chart, you can see that its including other charts using '0.0.x', which I would expect would cause the latest helm chart to always be used if a new helm chart is detected:

apiVersion: v2
name: list
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.0.1

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
appVersion: "1.0"

dependencies:
- name: postgresql
  version: 15.1.0
  repository: oci://registry-1.docker.io/bitnamicharts
- name: nats
  version: 1.1.10
  repository: https://nats-io.github.io/k8s/helm/charts/
- name: api-blocks
  version: 0.0.x
  repository: oci://harbor.vc-prod.k.home.net/list-charts
- name: api-lists
  version: 0.0.x
  repository: oci://harbor.vc-prod.k.home.net/list-charts
- name: controller-blocks
  version: 0.0.x
  repository: oci://harbor.vc-prod.k.home.net/list-charts
- name: controller-lists
  version: 0.0.x
  repository: oci://harbor.vc-prod.k.home.net/list-charts
- name: websocket
  version: 0.0.x
  repository: oci://harbor.vc-prod.k.home.net/list-charts

Here's an example of one of the microservices, there are of course more files in there ... values.yaml and files in the templates folder:

apiVersion: v2
name:
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.0.1

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
appVersion: "0.1.0"

# We use some of bitnami's helm chart standards
dependencies:
- name: common
  repository: oci://registry-1.docker.io/bitnamicharts
  tags:
  - bitnami-common
  version: 2.x.x

Expected behavior

Upon a 'refresh' I would expect argocd to see the new helm chart of the dependency and deploy the updated dependency using the latest helm chart.

Version

v2.10.6+d504d2b

Screenshot
the helm charts i'm working with:

showing that the version numbers are increasing of the dependencies:

the 'list' over-all helm chart, which includes the other helm charts, here it has version '0.0.3' which one would expect argocd to use this latest chart

Additional
If someone is asking the question, "so what is it doing if its not working", here's the answer. The over-all helm chart looks good, but it doesn't always use the latest helm chart for the dependencies when I release one. In the past I've clicked 'hard refresh' and it would load the latest helm charts, but that doesn't seem to work anymore.

'helm show chart' always shows the latest, so seems like argocd should be good to detect the latest helm charts:

$ helm show chart oci://harbor.vc-prod.k.home.net/list-charts/api-blocks
Pulled: harbor.vc-prod.k.home.net/list-charts/api-blocks:0.0.14
Digest: sha256:a33dfe52431339d3faae0727bf1eac180749d138b1150a99b3383ce5eaea43bc
apiVersion: v2
appVersion: 0.1.0
dependencies:
- name: common
  repository: oci://registry-1.docker.io/bitnamicharts
  tags:
  - bitnami-common
  version: 2.x.x
description: A Helm chart for Kubernetes
name: api-blocks
type: application
version: 0.0.14

[lknite]

Closing for the moment

[lknite]

Ran some more tests, still seems to be an issue.

[todaywasawesome]

@lknite It sounds like the issue is the secondary charts aren't getting refreshed when you want them to and instead you're getting the cache. One of the ways to solve this is by using multi-source apps which will actually check each repo individually for updates. https://argo-cd.readthedocs.io/en/stable/user-guide/multiple_sources/

Also, a hard refresh should pick up the changes.

On a side note, I personally would recommend against a setup like this. You're using floating chart tags so if something goes wrong you can't revert a git commit to get back to a previous state. That being said, I would classify it as a bug though low priority because there are workarounds available. PR would be welcome.

[lknite]

I wouldn't know where to being as far as submitting a PR, if you could maybe direct me to the files / methods involved I could take a look and see if that's something I might be able to handle. Am taking a look at the url you provided ...

[lknite]

agreed that a 'hard refresh' should be fixing this, i believe that's part of its intended purpose, but its definitely not working ...

[lknite]

Closing due to lack of interest.

[todaywasawesome]

agreed that a 'hard refresh' should be fixing this, i believe that's part of its intended purpose, but its definitely not working ...

If a hard refresh isn't working then it's a bug.