(Optionally) run helm dependency update before templating

[forquare]

Summary

Before attempting to template a Helm Chart, allow users to configure ArgoCD to run helm dependency update on the chart.

Motivation

In our environments we almost exclusively use Helm Charts based on an in-house library chart. In our application charts we soft-pin the dependency on the library chart to the patch version.

This works fine during building and packaging our charts, however we want to be able to roll out updates of the library chart across multiple clusters without rebuilding and republishing application charts. The way we achieve this is by building and packaging the chart, then decompressing and unarchiving it to remove the Chart.lock file and charts directory, then re-archiving and recompressing before publishing. So we have a bunch of helm charts that have had the dependencies ripped out of them.

This works nicely at the moment, ArgoCD:

1. pulls an application chart
2. attempts to template it and fails
3. therefore builds the dependency (pulling in the latest patch version of the library chart).
4. When the cache is invalided after 24 hours, ArgoCD repeats steps 1–3 allowing us to roll out library chart patches across multiple clusters - we are broadly happy that this takes 24 hours and understand we could tune the default-cache-expiration option to make this longer/shorter.

We would like to stop removing the Chart.lock file and charts directory for a few reasons:

1. We recently experienced some odd issues with removing these items using GNU tar with one specific chart (we've worked around this, so not much of a concern now).
2. We want the application charts to be used environments outside of our control, and would therefore like to keep the dependencies intact for these environments.
3. We have a concern that if ArgoCD starts to fail a sync if helm templating fails, then none of our charts will work in ArgoCD.
4. We have a concern that should something change in the way helm packages/verifies charts (e.g. they switch archive or compression formats, or start checking if certain headers are present that are unable to be preserved by our process) that we could get caught out by what we are doing.

We are currently unable to stop removing the Chart.lock file and charts directory because we rely on the behaviour that ArgoCD currently has.

Proposal

Prior to attempting to template the chart, run helm dependency update if the user has configured this to happen.

helm dependency update is a fairly expensive operation and certainly wouldn't want to be the default configuration.

The configuration could be global (i.e. make all applications using Helm do this), but I think that it would be much more valuable if it could be part of the Application manifest so that the behaviour could be specified on a per-Application basis.

---

I did look through the other issues and found #8728 which seems to have a similar solution for a different scenario.

Our scenario differs because we do always want to do a helm dependency update, whereas #8728 suggests that there should be a helm dependency list first to check if the update is needed - in our case where we want to bundle dependencies that might be older than the latest patch helm dependency list would report that the dependencies are satisfied even if there are later patch versions available.

Therefore I have raised this new enhancement request.

[andrii-korotkov-verkada]

This works fine during building and packaging our charts, however we want to be able to roll out updates of the library chart across multiple clusters without rebuilding and republishing application charts.

I think this isn't really how ArgoCD was designed to work. Debugging can get harder, since it's unclear which versions of dependencies might be used by the applications and why.