Hauler Version:
v2.0.2
Describe the Bug:
hauler store sync with add-dependencies: true fails to fetch a chart dependency whose
Chart.yaml declares an empty repository: "" (or a file://../x relative path). Same pattern
as #513 and #500. Those got partially fixed for v1.4.2 (#514, #510), but I'm still hitting a
residual failure on v2.0.2, just with a different error string than the original reports
(repo not found instead of path "..." not found).
Steps to Reproduce:
apiVersion: content.hauler.cattle.io/v1
kind: Charts
metadata: {name: repro}
spec:
charts:
- name: victoria-metrics-operator
repoURL: https://victoriametrics.github.io/helm-charts
version: "0.66.3"
add-dependencies: truehauler store sync -f repro.yaml
victoria-metrics-operator's own Chart.yaml declares:
- condition: crds.plain
name: crds
repository: ""
version: 0.0.*
The crds subchart really is vendored inside the downloaded chart archive. I confirmed this with helm pull oci://... --untar: charts/crds/ exists with a real Chart.yaml and templates/.
Hauler Log:
INF adding dependent chart [crds:0.0.*]
INF ↳ adding chart [crds] to the store
WRN ↳ failed to add dependent chart [crds]: repo not found... skipping...
Expected Behavior:
The vendored crds subchart gets found at <chartPath>/charts/crds and added to the store.
Actual Behavior:
Fetch fails with repo not found (note the double space, an empty string got interpolated into the message).
Additional Context:
I traced this to pkg/content/chart/chart.go, NewChart():
if registry.IsOCI(opts.RepoURL) {
chartRef = opts.RepoURL + "/" + name
} else if isUrl(opts.RepoURL) {
client.ChartPathOptions.RepoURL = opts.RepoURL
} else { // handles cases like grafana and loki
chartRef = opts.RepoURL + "/" + name
}add-dependencies' vendored-subchart resolution in cmd/hauler/cli/store/add.go correctly computes subchartPath := filepath.Join(chartPath, "charts", dep.Name) and passes it in as name with RepoURL: "". Since "" is neither OCI nor a valid URL, it falls into the else branch that's meant for named-repo aliases, and ends up building "" + "/" + subchartPath, a malformed string with a doubly-slashed prefix (something like //tmp/xyz/charts/crds). ChartPathOptions.LocateChart can't resolve that as a local file, falls through to a named-repo lookup instead, and fails with repo <emptystring> not found.
The subchartPath computation itself (the actual fix from #510/#514) looks correct to me. The bug seems specific to how NewChart re-derives chartRef from an already-fully-qualified local path when RepoURL is empty. A local path probably shouldn't go through the RepoURL + "/" + name branch at all.
Hauler Version:
v2.0.2
Describe the Bug:
hauler store syncwithadd-dependencies: truefails to fetch a chart dependency whoseChart.yamldeclares an emptyrepository: ""(or afile://../xrelative path). Same patternas #513 and #500. Those got partially fixed for v1.4.2 (#514, #510), but I'm still hitting a
residual failure on v2.0.2, just with a different error string than the original reports
(
repo not foundinstead ofpath "..." not found).Steps to Reproduce:
victoria-metrics-operator's ownChart.yamldeclares:The
crdssubchart really is vendored inside the downloaded chart archive. I confirmed this withhelm pull oci://... --untar:charts/crds/exists with a realChart.yamlandtemplates/.Hauler Log:
Expected Behavior:
The vendored
crdssubchart gets found at<chartPath>/charts/crdsand added to the store.Actual Behavior:
Fetch fails with
repo not found(note the double space, an empty string got interpolated into the message).Additional Context:
I traced this to
pkg/content/chart/chart.go,NewChart():add-dependencies' vendored-subchart resolution incmd/hauler/cli/store/add.gocorrectly computessubchartPath := filepath.Join(chartPath, "charts", dep.Name)and passes it in asnamewithRepoURL: "". Since""is neither OCI nor a valid URL, it falls into theelsebranch that's meant for named-repo aliases, and ends up building"" + "/" + subchartPath, a malformed string with a doubly-slashed prefix (something like//tmp/xyz/charts/crds).ChartPathOptions.LocateChartcan't resolve that as a local file, falls through to a named-repo lookup instead, and fails withrepo <emptystring> not found.The
subchartPathcomputation itself (the actual fix from #510/#514) looks correct to me. The bug seems specific to howNewChartre-deriveschartReffrom an already-fully-qualified local path whenRepoURLis empty. A local path probably shouldn't go through theRepoURL + "/" + namebranch at all.