(feat) outdated helm charts#1883
Merged
gianlucam76 merged 1 commit intoJul 20, 2026
Merged
Conversation
gianlucam76
force-pushed
the
newer-helm-chart-versions
branch
from
July 20, 2026 14:21
707a791 to
338e2c3
Compare
Sveltos can now tell you when a Helm chart deployed through a ClusterProfile or Profile has a newer version available upstream. This is detection only; nothing about what gets deployed changes. Once a chart has been successfully deployed to a cluster, Sveltos now also remembers exactly which chart, which repository, and which credentials were actually used for that specific deployment. That information used to only exist transiently at deploy time. Now it's kept around per cluster so it doesn't need to be re-derived later, which matters because chart names, versions, and repository locations can be templated and resolve differently per cluster. A background process, running only on the main instance (not on sharded instances, since it needs visibility into every cluster to avoid duplicate work), periodically walks every currently deployed chart, groups together deployments that are actually the same chart from the same source, and checks each one just once against its upstream repository or registry to see what versions are actually published. For each deployment it then knows two things: whether a newer version exists at all, and whether a newer patch release exists within the same minor version line. Any repository or registry that can't be reached is skipped and logged rather than stopping the whole check, and each check has a timeout so one slow or unresponsive source can't hold up the rest. The result is recorded directly on the same per-cluster object that already tracks that chart's deployment status, so it's visible per cluster rather than as one blended answer across a whole fleet. A metric exposes which deployments are currently behind, and it's kept accurate throughout each check. Two additional small metrics expose the health of the checker itsel: when it last finished a run, and how many checks failed. So a broken or stuck checker is visible rather than silently indistinguishable from "everything is up to date." The check interval is configurable and can be turned off entirely.
gianlucam76
force-pushed
the
newer-helm-chart-versions
branch
from
July 20, 2026 17:38
338e2c3 to
d1db4d6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sveltos can now tell you when a Helm chart deployed through a ClusterProfile or Profile has a newer version available upstream. This is detection only; nothing about what gets deployed changes.
Once a chart has been successfully deployed to a cluster, Sveltos now also remembers exactly which chart, which repository, and which credentials were actually used for that specific deployment. That information used to only exist transiently at deploy time. Now it's kept around per cluster so it doesn't need to be re-derived later, which matters because chart names, versions, and repository locations can be templated and resolve differently per cluster.
A background process, running only on the main instance (not on sharded instances, since it needs visibility into every cluster to avoid duplicate work), periodically walks every currently deployed chart, groups together deployments that are actually the same chart from the same source, and checks each one just once against its upstream repository or registry to see what versions are actually published. For each deployment it then knows two things: whether a newer version exists at all, and whether a newer patch release exists within the same minor version line.
Any repository or registry that can't be reached is skipped and logged rather than stopping the whole check, and each check has a timeout so one slow or unresponsive source can't hold up the rest.
The result is recorded directly on the same per-cluster object that already tracks that chart's deployment status, so it's visible per cluster rather than as one blended answer across a whole fleet. A metric exposes which deployments are currently behind, and it's kept accurate throughout each check.
Two additional small metrics expose the health of the checker itsel: when it last finished a run, and how many checks failed. So a broken or stuck checker is visible rather than silently indistinguishable from "everything is up to date."
The check interval is configurable and can be turned off entirely.