<p>Figured out a way, but it might not be the most elegant.</p>
<p>First, we render the chart locally and then use <code>tree</code> to print out the subdirectories with their sizes in a human-readable format.</p>
<pre class="lang-sh prettyprint-override"><code>helm template . --output-dir=file-size-test
tree --du -h file-size-test
</code></pre>
<p>This produces an output similar to:</p>
<pre><code>[340M]  testing123
└── [340M]  chart_name
    ├── [ 91K]  charts
    │   ├── [ 58K]  sub-chart
    │   │   └── [ 58K]  templates
    │   │       ├── [1.3K]  deployment.yaml
    │   │       ├── [ 411]  config.yaml
    │   │       ├── [ 579]  service.yaml
    │   │       └── [ 359]  serviceaccount.yaml
&lt;truncated&gt;
    └── [340M]  templates
        ├── [ 68M]  deployment.yaml
        ├── [136M]  config1.yaml
        ├── [136M]  config2.yaml
        └── [1.3K]  ingress.yaml
</code></pre>
<p>So now I've found that the issue seems to be the massive <code>config1.yaml</code> and <code>config2.yaml</code> files.</p>
<p>While this doesn't exactly answer the question of <em>how</em> to find which have been ignored, it at least points to which might not have been ignored.</p>

CC BY-SA 4.0
2022-10-26T20:28:32.607Z
2022-10-26T21:50:24.847Z
2022-10-26T21:50:24.847Z
Meow_ly
<p>I'm installing a local Helm chart; however, I keep getting an error <code>Error: UPGRADE FAILED: create: failed to create: Request entity too large: limit is 3145728</code>. From searching other SO/Stack Exchange questions, this is typically caused by unnecessary files mistakenly included in the chart. The way to resolve this, is to add those entries to a <a href="https://helm.sh/docs/chart_template_guide/helm_ignore_file/" rel="nofollow noreferrer"><code>.helmignore</code> file</a>.</p>
<p>My chart has a <code>.helmignore</code> file, which should be excluding all unnecessary artifacts within my chart, but I'm still getting the error. So my thought is that my <code>.helmignore</code> entries aren't quite targeting the files that they should be.</p>
<p>I've tried running them with the <code>--debug</code> flag (didn't show anything more interesting):</p>
<pre><code>upgrade.go:139: [debug] preparing upgrade for chartname
upgrade.go:520: [debug] copying values from chartname (v11) to new release.
upgrade.go:147: [debug] performing update for chartname
upgrade.go:319: [debug] creating upgraded release for chartname
Error: UPGRADE FAILED: create: failed to create: Request entity too large: limit is 3145728
helm.go:88: [debug] Request entity too large: limit is 3145728ffff
create: failed to create
helm.sh/helm/v3/pkg/storage/driver.(*Secrets).Create
        helm.sh/helm/v3/pkg/storage/driver/secrets.go:164
helm.sh/helm/v3/pkg/storage.(*Storage).Create
        helm.sh/helm/v3/pkg/storage/storage.go:69
helm.sh/helm/v3/pkg/action.(*Upgrade).performUpgrade
        helm.sh/helm/v3/pkg/action/upgrade.go:320
helm.sh/helm/v3/pkg/action.(*Upgrade).RunWithContext
        helm.sh/helm/v3/pkg/action/upgrade.go:148
main.newUpgradeCmd.func2
        helm.sh/helm/v3/cmd/helm/upgrade.go:200
github.com/spf13/cobra.(*Command).execute
        github.com/spf13/cobra@v1.2.1/command.go:856
github.com/spf13/cobra.(*Command).ExecuteC
        github.com/spf13/cobra@v1.2.1/command.go:974
github.com/spf13/cobra.(*Command).Execute
        github.com/spf13/cobra@v1.2.1/command.go:902
main.main
        helm.sh/helm/v3/cmd/helm/helm.go:87
runtime.main
        runtime/proc.go:255
runtime.goexit
        runtime/asm_arm64.s:1133
UPGRADE FAILED
main.newUpgradeCmd.func2
        helm.sh/helm/v3/cmd/helm/upgrade.go:202
github.com/spf13/cobra.(*Command).execute
        github.com/spf13/cobra@v1.2.1/command.go:856
github.com/spf13/cobra.(*Command).ExecuteC
        github.com/spf13/cobra@v1.2.1/command.go:974
github.com/spf13/cobra.(*Command).Execute
        github.com/spf13/cobra@v1.2.1/command.go:902
main.main
        helm.sh/helm/v3/cmd/helm/helm.go:87
runtime.main
        runtime/proc.go:255
runtime.goexit
        runtime/asm_arm64.s:1133
</code></pre>
<p>I also tried it with the <code>--dry-run</code> flag and the chart succeeded. So at this point I'm not sure how to find what's bloating my chart.</p>
<p>How can I tell which files are actually getting ignored (or which are included) when I run a <code>helm install</code> or <code>helm upgrade</code>?</p>

<kubernetes><helm><kubernetes-helm>
How to determine which files are ignored by a .helmignore file?
Meow_ly
# How to determine which files are ignored by a .helmignore file?

(Asked by: username_0 on 2022-10-26)

I'm installing a local Helm chart; however, I keep getting an error Error: UPGRADE FAILED: create: failed to create: Request entity too large: limit is 3145728. From searching other SO/Stack Exchange questions, this is typically caused by unnecessary files mistakenly included in the chart. The way to resolve this, is to add those entries to a .helmignore file.
My chart has a .helmignore file, which should be excluding all unnecessary artifacts within my chart, but I'm still getting the error. So my thought is that my .helmignore entries aren't quite targeting the files that they should be.
I've tried running them with the --debug flag (didn't show anything more interesting):
upgrade.go:139: [debug] preparing upgrade for chartname
upgrade.go:520: [debug] copying values from chartname (v11) to new release.
upgrade.go:147: [debug] performing update for chartname
upgrade.go:319: [debug] creating upgraded release for chartname
Error: UPGRADE FAILED: create: failed to create: Request entity too large: limit is 3145728
helm.go:88: [debug] Request entity too large: limit is 3145728ffff
create: failed to create
helm.sh/helm/v3/pkg/storage/driver.(*Secrets).Create
        helm.sh/helm/v3/pkg/storage/driver/secrets.go:164
helm.sh/helm/v3/pkg/storage.(*Storage).Create
        helm.sh/helm/v3/pkg/storage/storage.go:69
helm.sh/helm/v3/pkg/action.(*Upgrade).performUpgrade
        helm.sh/helm/v3/pkg/action/upgrade.go:320
helm.sh/helm/v3/pkg/action.(*Upgrade).RunWithContext
        helm.sh/helm/v3/pkg/action/upgrade.go:148
main.newUpgradeCmd.func2
        helm.sh/helm/v3/cmd/helm/upgrade.go:200
github.com/spf13/cobra.(*Command).execute
        github.com/spf13/cobra@v1.2.1/command.go:856
github.com/spf13/cobra.(*Command).ExecuteC
        github.com/spf13/cobra@v1.2.1/command.go:974
github.com/spf13/cobra.(*Command).Execute
        github.com/spf13/cobra@v1.2.1/command.go:902
main.main
        helm.sh/helm/v3/cmd/helm/helm.go:87
runtime.main
        runtime/proc.go:255
runtime.goexit
        runtime/asm_arm64.s:1133
UPGRADE FAILED
main.newUpgradeCmd.func2
        helm.sh/helm/v3/cmd/helm/upgrade.go:202
github.com/spf13/cobra.(*Command).execute
        github.com/spf13/cobra@v1.2.1/command.go:856
github.com/spf13/cobra.(*Command).ExecuteC
        github.com/spf13/cobra@v1.2.1/command.go:974
github.com/spf13/cobra.(*Command).Execute
        github.com/spf13/cobra@v1.2.1/command.go:902
main.main
        helm.sh/helm/v3/cmd/helm/helm.go:87
runtime.main
        runtime/proc.go:255
runtime.goexit
        runtime/asm_arm64.s:1133

I also tried it with the --dry-run flag and the chart succeeded. So at this point I'm not sure how to find what's bloating my chart.
How can I tell which files are actually getting ignored (or which are included) when I run a helm install or helm upgrade?

**Tags:** kubernetes, helm, kubernetes-helm


---

## 1 answers

### Answer by username_0 on 2022-10-26. Score: 1 | Accepted answer

Figured out a way, but it might not be the most elegant.
First, we render the chart locally and then use tree to print out the subdirectories with their sizes in a human-readable format.
helm template . --output-dir=file-size-test
tree --du -h file-size-test

This produces an output similar to:
[340M]  testing123
└── [340M]  chart_name
    ├── [ 91K]  charts
    │   ├── [ 58K]  sub-chart
    │   │   └── [ 58K]  templates
    │   │       ├── [1.3K]  deployment.yaml
    │   │       ├── [ 411]  config.yaml
    │   │       ├── [ 579]  service.yaml
    │   │       └── [ 359]  serviceaccount.yaml

    └── [340M]  templates
        ├── [ 68M]  deployment.yaml
        ├── [136M]  config1.yaml
        ├── [136M]  config2.yaml
        └── [1.3K]  ingress.yaml

So now I've found that the issue seems to be the massive config1.yaml and config2.yaml files.
While this doesn't exactly answer the question of how to find which have been ignored, it at least points to which might not have been ignored.


---

