-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
public registry proxy not getting the latest Chart versions anymore? again? #7
Comments
you are right, we need to release the latest version that contains the fix. |
I'll reset the current cache, so it should work again. |
Thanks a lot, this helped 👍 |
Today I noticed this issue in my installation. Restarting the proxy "fixed" the issue for now. How can I prevent this from happening again? I don't want to restart the proxy every night. |
The new version of the images fixes the issue. I need to updat the helm chart |
@Vad1mo, could you please tell me if the issue with version "lag" has been fixed in the public proxy? Because for chart museum repository https://argoproj.github.io/argo-helm the tags are lagging if I use public proxy https://chartproxy.container-registry.com/argoproj.github.io/argo-helm/argo-cd |
Hi guys Whilst pulling the latest Grafana Helm Chart (7.3.7) I ran into the same error. When do you deploy the fix? Could you please reset the current cache as this may solve the issue? |
Any Updates on that? |
I just hit the same issue. I retried the pull replication many times before, trying to see if I could get latest cilium chart 1.15.5 synced over, but it kept missing this latest chart. It seems the sync process would need to list all available charts first, and it is in this phase that it could only see cilium chart up to 1.15.4. After rollout restarting chartproxy deployment, and resyncing it, it works. So this is still a bug. |
This problem arises because in the docker image version used in the chart ( Because of this, the data about helm chart versions will only update when the in-memory cache overflows and entries start being "evicted" Therefore, the data about available chart versions is updated after restarting The docker image used in the chart is built approximately from this commit. The code shows that entries are placed in the cache without specifying a time-to-live (here and here). You need to use one of the docker images that are now regularly built from the main branch. The most up-to-date tag version at the moment is In the current version of the code, the cache entry time-to-live is set and regulated by environment variable values (here and here). You will need to set the cache entry time-to-live through the environment variables:
You can get the full list of available docker image tags using the imgpkg utility:
|
@verdel : Thanks! I am currently using helm-charts-oci-proxy tag version '1.2.2', would this chart version also have the same issue as latest/a3a35bc? |
@haiwu, In all versions of the helm chart, including the one currently in the main branch, the tag of the used docker image is latest. The tag
You will need to change the tag through the chart's values ( |
Hi there
There seems to be the same issue as in #3.
I tried to get the latest chart for camunda-platform.
The tags list (https://chartproxy.container-registry.com/v2/helm.camunda.io/camunda-platform/tags/list) does not contain the tag 8.3.1, despite the index.yaml at the referenced repository has.
I first thought it might be an issue with the remoteside (index.yaml or something similar), but this seems to be okay. I can directly pull from the original site AND I setup chartproxy in a docker container and tried to pull from there: this works too. So my assumption is that either the public chartproxy registry has not been updated or there is another not yet known issue with the index update,.
I'd be very happy if you could have a look!
Thanks, Pascal
The text was updated successfully, but these errors were encountered: