Whitelisting in .helmignore with '/*' returns "chart metadata (Chart.yaml) missing"

[SimonTheLeg]

Hi guys,

I am trying a whitelist approach with the following .helmignore

/*
!.helmignore
!Chart.yaml
!templates
!values.yaml

Unfortunately this gives me the following error:

Error: chart metadata (Chart.yaml) missing

Is this the desired behavior or am I missing something?

helm/tiller version:

$ helm version
Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

[bacongobbler]

hmm. I don't think this is intentional behaviour, but I can see how this happens. I don't think a whitelist approach was in mind when .helmignore was first implemented :)

You could probably write a unit test for ParseFile and confirm that these set of rules end up cancelling each other out. My assumption that

!.helmignore
!Chart.yaml

effectively cancel each other out, ignoring everything in the current directory.

[SimonTheLeg]

Thanks for the answer! Unfortunately I don't think that this is the case. Leaving out "!.helmignore" like this, produces the same error:

/*
!Chart.yaml
!templates
!values.yaml

However I personally think this should work like .gitignore does, which will ignore everything exept Chart.yaml, templates, and values.yaml. Is there a reason why this behaviour is different in .helmignore or is it just that no one has made a feature request like that yet?

On another note, maybe I am on the wrong track here altogether. So I started with the .helmignore file, because tiller wasn't able to create a deployment anymore due to the configmap being to big from all the new files I added into the repo. What I don't really understand is why blacklisting is the "preferred" way in helm. Like I constantly find myself in the situation where I add new files and folders to the root of my repo, all of which I have to manually add to .helmginore (which more often than not I forget 🙈). On the other side I feel like helm doesn't really have a lot of files/folders that need to be added. Additionally from this document, I would assume their structure is pretty much fixed . As a helm beginner this is really confusing to me. Is there something I am missing?

[bacongobbler]

Yeah that was a simple example. Basically the issue revolves around two negation arguments in the same directory. Instead of a whitelist, you end up with everything being ignored. :)

Is there a reason why this behaviour is different in .helmignore or is it just that no one has made a feature request like that yet?

This is the first time someone's asked for this feature request AFAIK. Feel like working on a PR?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[bgehman]

Bump -- seeing the same issue. .helmignore should work exactly like .dockerignore and .gitignore -- which allows the whitelist approach instead of the blacklist approach. All my .dockerignore and .gitignore are set up to specifically whitelist (how can you ever predict what might show up on build / CI systems?)

My .helmignore:

# Ignore everything
*

# Except:
!*.yaml
!templates/

Gets error:

$ helm lint

[ERROR] templates/: chart metadata (Chart.yaml) missing

/remove-lifecycle stale

[ickedude]

+1
I am now facing the same issue.
If a line starts with ! you will get the message Error: chart metadata (Chart.yaml) missing.
Ignoring files starting with ! is supported by escaping it with \. Also files starting with space or # needs to be escaped as it needs to be done in .gitignore.

[rcorre]

Use case: we've seen a lot of teams unintentionally packaging the tarballs of prior builds in their chart. For example, foo-0.3.0.tgz will contain foo-0.2.0.tgz and foo-0.1.0.tgz within it. We'd like to recommend a helmignore with:

*.tgz
!charts/

As mentioned in the OP, this errors with Error: chart metadata (Chart.yaml) missing. Omitting !charts/ will ignore dependent charts.

[rcorre]

Basically the issue revolves around two negation arguments in the same directory

The example I posted above only has one negation ... @bacongobbler should I open a separate issue or do you think it is related?

[bacongobbler]

No, I think it's related. Adding a single negation worked as it was intended: it marked anything in the root directory other than the charts directory (including Chart.yaml) as something helm package should not include, so it's working exactly as intended.

In your case, you probably want something like the following:

!Chart.yaml
!templates/
!charts/

Which would fail as others have discovered because of the double negation.

[bacongobbler]

Or, perhaps the following might work in your case?

*.tgz
!charts/*.tgz

Give that a shot.

[rcorre]

@bacongobbler no luck:

[rodencor@heredesk foo]$ cat .helmignore
*.tgz
!charts/*.tgz
[rodencor@heredesk foo]$ helm dep up
Error: chart metadata (Chart.yaml) missing
[rodencor@heredesk foo]$ rm .helmignore
[rodencor@heredesk foo]$ helm dep up
Hang tight while we grab the latest from your chart repositories...
...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: connect: connection refused
...Successfully got an update from the "here-helm-s3" chart repository
...Successfully got an update from the "here-helm" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 2 charts

[Simon3]

+1

Btw I was wondering, why isn't the default behaviour to ignore everything except the "Chart File Structure" exposed at https://github.com/helm/helm/blob/master/docs/charts.md#the-chart-file-structure ? Why would we want to send other files to Tiller?

[galindro]

I really would love to use .helmignore as .gitignore. This is my usecase:

# .helmignore file contents
!Chart.yaml
!val*.yaml
!templates/
*

helm lint .
==> Linting .
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/: validation: chart.metadata is required

Error: 1 chart(s) linted, 1 chart(s) failed

helm version: 3.0.2

[bacongobbler]

Just deleted all “+1” comments. If you want to upvote this ticket, please use the “thumbs up” reaction in the original comment. That way we can keep the discussion focused without having to filter out any “+1” comments. Thanks!

[AlexStasko]

Is there any news?
I've also run into this issue. I'm trying to setup CI/CD for my charts. I have one chart per git repo and all files in the root directory. During the build, the CI tool creates a lot of temp files, and once it executes helm package all these files are placed in tgz archive.
I'd love to have the ability to whitelist only necessary files in .helmignore as it works in .gitignore.

[bacongobbler]

No news/updates on this topic to share. If you're interested in fixing this, we'd welcome the effort. Though I don't think we can actually make the change until Helm 4 as introducing/fixing this behaviour would result in compatibility breakers.

[taliastocks]

No news/updates on this topic to share. If you're interested in fixing this, we'd welcome the effort. Though I don't think we can actually make the change until Helm 4 as introducing/fixing this behaviour would result in compatibility breakers.

I think we can avoid breaking most compatibility due to the fact that this feature, as written, is nearly useless:

• As written, all rules must match /Chart.yaml, otherwise the helm chart stops working entirely.
• This means, more or less, that the only useful negative rule is !*.yaml.

To maintain most backwards compatibility, we could treat a set of rules that, aside from directory rules, only contain negatives as implicitly including * as a positive rule:

• !*.yaml would continue to exclude all non-yaml files when included on its own in a .helmignore.
• Directory rules would continue to work as-is due to the above exception, and files in these directories would not be included because excluded directories are not traversed.

This isn't perfect, however, because some users may currently include redundant positive rules alongside !*.yaml, for example README.md. The presence of these rules doesn't currently add anything to the !*.yaml negative rule, but nonetheless they may appear in the wild.

[JuryA]

It is also worth noting that the documentation states:

The .helmignore file supports Unix shell glob matching, relative path matching, and negation (prefixed with !). Only one pattern per line is considered.

The "cryptic" sentence

There is no support for '!' as a special leading sequence.

is misleading - what does it mean "special leading sequence"? In contrast to the earlier statement, it is either a contradiction or it can also be mistakenly understood that (given the earlier point about whitespace in filenames) these are files starting with an exclamation mark (!). Simply put: That sentence is semantically wrong.

I think that the solution should be to simply mimic the behavior of .gitignore because this is the first thing that comes to mind...

[christian-elsee]

and there goes an hour of my life wasted.. why would you guys name something after the canonical standard that is .gitignore, but then not have it do exactly the same thing?