helm dependency update: Command Reference for CI/CD
Resolve and vendor a chart subchart dependencies.
helm dependency update reads the dependencies in Chart.yaml, downloads matching subcharts into charts/, and refreshes Chart.lock. This reference distinguishes it from dependency build and shows where it fits in a CI build.
Common flags and usage
- dependency update <chart>: resolve, download subcharts, rewrite Chart.lock
- dependency build <chart>: download exactly what Chart.lock pins (reproducible)
- dependency list <chart>: show declared dependencies and their status
- --skip-refresh: do not refresh repo indexes first
- Requires the dependency repos to be added first
Example
helm repo add bitnami https://charts.bitnami.com/bitnami --force-update
helm repo update
helm dependency update ./charts/web # writes charts/ and Chart.lockIn CI
Use dependency build (not update) when Chart.lock is committed, so CI installs exactly the pinned versions reproducibly; update re-resolves and can drift. Either way, add and update the dependency repos first, or resolution fails with "no repository definition".
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodesKey takeaways
- update re-resolves and rewrites Chart.lock; build installs the pinned lock.
- For reproducible CI with a committed lock, prefer dependency build.
- Add the dependency repos before resolving, or it fails.