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

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"}

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 33
  • Comments: 18 (6 by maintainers)

Commits related to this issue

Most upvoted comments

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!

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.

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.

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.

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?

+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?

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