Docs do not specify location for .helmignore

[pmocek]

Helm's documentation of a chart's .helmignore file does not state where helm will look for that file. (Or, alternatively, helm ignores .helmignore in present working directory.)

By experimenting with helm lint I found that helm seems to look exclusively in the chart directory for .helmignore:

Linting fails--cryptically--unless I remove charts/README.md (which I created specifically so that I can check into git my chart's charts directory, which I understand to be required, even if no dependent charts exist):

$ helm lint foo
==> Linting foo
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/: error unpacking README.md in foo: Chart.yaml file is missing
[ERROR] : unable to load chart
    error unpacking README.md in foo: Chart.yaml file is missing

Error: 1 chart(s) linted, 1 chart(s) failed
$ rm -v foo/charts/README.md
foo/charts/README.md
$ helm lint foo
==> Linting foo
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

The .helmignore in my working directory (parent of chart directory) contains a relevant directive from both the perspective of the chart and from my PWD:

$ grep README .helmignore
# Ignore the README in the charts directory
charts/README.md
*/charts/README.md

Helm seems to ignore that file unless I put it in the chart directory:

$ touch foo/charts/README.md
$ helm lint foo
==> Linting foo
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/: error unpacking README.md in foo: Chart.yaml file is missing
[ERROR] : unable to load chart
    error unpacking README.md in foo: Chart.yaml file is missing

Error: 1 chart(s) linted, 1 chart(s) failed
$ mv -v .helmignore foo/
.helmignore -> foo/.helmignore
$ helm lint foo
==> Linting foo
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

[awhitepl]

I would like to add on to this that the docs do not specify if adding a .helmignore file to a chart requires a new helm dependency build/up. I think logically that it does but to remove any ambiguity about this in the documentation would make sense.