Support scanning for updates to Helm-backed ArgoCD Application CRDs
jstewart612 opened this issue · 11 comments
Is your feature request related to a problem? Please describe.
ArgoCD has the concept of Application CRDs. These can source from Helm charts themselves, but do not install helm in the traditional manner. Rather, it renders the templates, and then applies those to the cluster. As such, you do not see helm installs with the helm cli, and as such, Nova seems not to be able to find them and assess upgradable candidates.
This feature request is to add this functionality to Nova.
Describe the solution you'd like
Add a flag to Nova to allow it to also scan ArgoCD Application CRD instances on your cluster and check them for updates if they are based on Helm charts.
Describe alternatives you've considered
I am unaware that any exist.
Additional context
I don't see that any is required here but let me know if you do.
If it is helpful for implementation, the fields you'd be looking to scan of that CRD are:
.spec.source.helm.chart: the chart name
.spec.source.helm.targetRevision: A Semantic Release compatible version value
Thanks for the request! This is a great idea
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
still needed
A colleague actually did work on this locally and I have recommended submission here for wider adoption of the feature.
+1 on this feature, we have a lot of external applications implement by gitops approach - argocd then we are finding a way to check if whether they was update or release.
@lucasreed is it safe to say no maintainer of this repository will accept the last PR submitted to address this issue while it requires an additional external binary? That you compel a native library be used for the purpose? This is not to voice disagreement: merely to establish the terms.
Hey @jstewart612, I'm afraid I am no longer a maintainer here, so I'll let someone else answer that.
Catching up on this now, and I would say that is correct @jstewart612. Adding another third-party binary introduces maintenance cost that we are not willing to incur at this time. If we were to implement a dynamic client instead, that could be covered by unit tests and much easier/safer to maintain. Additionally, it would not require a new method of keeping up on dependencies beyond dependabot.
Flux is a great gitops tool and widely used.