"helm dep build" fails if requirements.yaml contains local dependencies and remote one

[wemu]

Hello

I have a chart that contains two dependencies, one is located in our internal helm registry, one is copied into the charts sub-directory. I can either use "helm dep build" with only the one from the registry or the local one, but not in combination:

$ tree .
|-- Chart.yaml
|-- README.md
|-- charts
|   `-- oraclepdb
|       |-- Chart.yaml
|       `-- templates
|           `-- oraclepdb.yaml
|-- requirements.yaml
|-- templates
|   |-- _helpers.tpl
|   |-- deployment.yaml
|   |-- ingress.yaml
|   |-- secrets.yaml
|   `-- svc.yaml
`-- values.yaml

The helm registry is added:

$ helm repo list
NAME    URL
stable  https://kubernetes-charts.storage.googleapis.com
local   http://127.0.0.1:8879/charts
mobi    https://git.bitbucket.server/projects/K8S/repos/charts/raw

Using this requirements yaml:

$ more requirements.yaml
dependencies:
  - name: mobi-postgresql
    version: 1.0.1
    repository: "@mobi"
    alias: postgresql
  - name: oraclepdb
    version: 0.0.1

and then "helm dep list"

NAME            VERSION REPOSITORY      STATUS
mobi-postgresql 1.0.1   @mobi           missing
oraclepdb       0.0.1                   unpacked

then trying "helm dep update" fails:

Error: no repository definition for . Please add them via 'helm repo add'
Note that repositories must be URLs or aliases. For example, to refer to the stable
repository, use "https://kubernetes-charts.storage.googleapis.com/" or "@stable" instead of
"stable". Don't forget to add the repo, too ('helm repo add').

for some reason the sub-chart in charts is no longer a local one.

Just using this requirements.yaml and running "helm dep update" works:

dependencies:
  - name: mobi-postgresql
    version: 1.0.1
    repository: "@mobi"
    alias: postgresql

It also works if both sub-charts are copied and extracted already.

I tried pointing to the file using this requirements.yaml:

dependencies:
  - name: mobi-postgresql
    version: 1.0.1
    repository: "@mobi"
    alias: postgresql
  - name: oraclepdb
    version: 0.0.1
    repository: "file://./charts/"

$ helm dep list
NAME            VERSION REPOSITORY              STATUS
mobi-postgresql 1.0.1   @mobi                   missing
oraclepdb       0.0.1   file://./charts/        unpacked

$ helm dep build
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "mobi" chart repository
...Successfully got an update from the "stable" chart repository
...Unable to get an update from the "local" chart repository (http://127.0.0.1:8879/charts):
        Get http://127.0.0.1:8879/charts/index.yaml: dial tcp 127.0.0.1:8879: connectex: No connection could be made because the target machine actively refused it.
Update Complete. ⎈Happy Helming!⎈
Saving 2 charts
Downloading mobi-postgresql from repo https://git.mobi.mobicorp.ch/projects/K8S/repos/charts/raw
Save error occurred:  chart metadata (Chart.yaml) missing
Deleting newly downloaded charts, restoring pre-update state
Error: chart metadata (Chart.yaml) missing

this does not download the mobi-postgresql file anymore.

So currently I can only use remote charts or both within the charts sub-directory. But mixing them havong one from remote and one unpacked (in case some chart does not yet offer some values, so we temporarly copy them) does somehow not work.

using helm 2.8.2 on windows.

Is there a workaround?

[morstad]

I am seeing similar issue with helm dependency update - trying to use requirements.yaml to alias and conditionally include local subcharts + pull in remote dependencies. 'helm dependency update' requires a repository path be provided for all entries in requirements.yaml so I added file://./charts/mychart for local subchart. The dependency update fails with : 'Save error occurred: directory ../charts/mychart not found' even though the path listed exists.

Commenting out local subcharts when running 'helm dependency update' and then uncommenting before install to get around issue temporarily.

[ejether]

I'm also seeing this same issue currently.

[ejether]

I've been looking into this and have reached some confusing dead ends.
This os.Stat() call in this func https://github.com/kubernetes/helm/blob/master/pkg/resolver/resolver.go#L132 is behaving as if the path does not exist. I copied that function identically to do a smoke test and with identical inputs, the smoke test can find the file path and the func in resolver.godoes not.

I'm not very experienced with go, but I cannot understand how the same os.Stat() call will return different results.

[sgandon]

Also experiencing this on mac !
Only with extracted charts and the requirements.yaml file in order to have conditions on subchart, the helm dependencies update fails telling it does not find a folder that in fact exists !

[sgandon]

The only workaround that I found for this is to place all the sub charts into a subchart folder and have the requirements.yaml like this (with your example)

dependencies:
  - name: mobi-postgresql
    version: 1.0.1
    repository: "@mobi"
    alias: postgresql
  - name: oraclepdb
    version: 0.0.1
    repository: "file://subcharts/oraclepdb"

But this is kind of ugly in my opinion.
I really would like to have this bug fixed.

[ejether]

Depending on how you are using the Helm requirements file, this may be of interest: https://github.com/reactiveops/autohelm

It provides a declarative wrapper for helm.

[sgandon]

@ejether, I am also looking at the helm code and I think I found the reason why the os.Stat() fails to find the folder.
This is because the calling function downloadAll ( https://github.com/kubernetes/helm/blob/b6335b7dfeb0e68952ee914877fe456ecd257779/pkg/downloader/manager.go#L212 ) is renaming the charts folder to tmpcharts during the update thus making our unpacked chart not foundable for that duration.

[sgandon]

I'll propose a PR to fix this soon. I made it work locally but I need some more testing and unfortunatly there are no tests for that daowloadAll method and I am a Go rooky for writing it from scratch.

[ejether]

Thanks for working on it.

[derrickburns]

Any progress on this? It has been a YEAR.

[anoora17]

I have the same problem

[maciej-sawicki-codilime]

+1

[YingjunHu]

Still seeing the problem

[iulianbaranai]

Same problem was also described in issue 5531 - now closed as duplicate.
Two pull requests are opened at the moment: 3987 and 3422.
A workaround is described in above comment.

[djuarezg]

Experiencing this as well. Painful as hell, causes ugly workarounds.

[jasondamour]

Still present in helm 3 Chart.yaml v2

[nkleroux]

Am I making the correct assumption that if you remove the repository option, it would automatically check in the charts folder?

helm/pkg/downloader/manager.go

Line 219 in 985827d

// No repository means the chart is in charts directory

Seems to be working for me, unless I'm missing something vital.

[sjmiller609]

We have worked around this problem by wrapping external charts with local charts, and doing 'helm dep update .' in the wrapping subchart before packaging the top-level umbrella chart.

[bacongobbler]

closing as inactive. Please re-open if this continues to show itself in more recent versions of Helm 3. Thanks.