helm dependency update: Usage & Common CI Errors
Vendor a chart's subcharts so it can render and install.
helm dependency update resolves the dependencies listed in Chart.yaml, downloads them into the charts/ directory, and writes Chart.lock. Without it, a chart with subcharts cannot template, lint, or install.
What it does
helm dependency update CHART reads the dependencies in Chart.yaml, fetches each from its repository, places the .tgz files in charts/, and records resolved versions in Chart.lock. helm dependency build is the companion that fetches exactly what Chart.lock pins (reproducible CI), versus update which re-resolves and may bump versions.
Common usage
helm dependency update ./charts/web
helm dependency build ./charts/web # honour Chart.lock exactly
helm dependency list ./charts/web
helm dependency update ./charts/web && helm template web ./charts/webCommon errors in CI
"found in Chart.yaml, but missing in charts/ directory" on template/install/package means dependencies were never fetched. Run dependency update (or build) first. "no repository definition for <url>" means a dependency points at a repo you have not helm repo add-ed; add it before updating. For reproducible CI prefer helm dependency build, which errors with "Chart.lock is out of sync with Chart.yaml" if the lock is stale, forcing you to regenerate it deliberately rather than silently pulling newer subchart versions on every build.
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 nodes