There is one more problem iirc -- today Helm only respects .helmignore for helm package. It will ignore .helmignore if the chart is unpacked/untarred

.helmignore definitely ignores files during helm runtime operations too - on both a packed ann unpacked chart - including helm template, install, etc. Here is an unpacked example:

d=$(mktemp -d)
mkdir -p $d/templates $d/files

cat > $d/Chart.yaml <<'EOF'
apiVersion: v2
name: test
version: 0.1.0
EOF

cat > $d/templates/cm.yaml <<'EOF'
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Chart.Name }}-cm
data:
{{- (.Files.Glob "files/*").AsConfig | nindent 2 }}
EOF

cat > $d/templates/pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: {{ .Chart.Name }}-pod
spec:
  containers:
  - name: nginx
    image: nginx:alpine
EOF

cat > $d/files/test.conf <<'EOF'
test including .conf file
EOF

cat > $d/files/test.txt <<'EOF'
test including .txt file
EOF

tree $d

echo '\n=== template WITHOUT .helmignore ==='
helm template $d

cat > $d/.helmignore <<'EOF'
*.txt
pod.yaml
EOF

echo '\n=== template WITH .helmignore ==='
helm template $d

echo '\n=== install WITH .helmignore ==='
helm install --dry-run test $d

should return

/var/folders/7j/bxcg16h177zfgfkzdlv8rb240000gn/T/tmp.5QdzSnmxHz
├── Chart.yaml
├── files
│   ├── test.conf
│   └── test.txt
└── templates
    ├── cm.yaml
    └── pod.yaml

3 directories, 5 files

=== template WITHOUT .helmignore ===
---
# Source: test/templates/cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
data:
  test.conf: |
    test including .conf file
  test.txt: |
    test including .txt file
---
# Source: test/templates/pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: nginx
    image: nginx:alpine

=== template WITH .helmignore ===
---
# Source: test/templates/cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
data:
  test.conf: |
    test including .conf file

=== install WITH .helmignore ===
level=WARN msg="--dry-run is deprecated and should be replaced with '--dry-run=client'"
NAME: test
LAST DEPLOYED: Wed Dec 17 22:14:13 2025
NAMESPACE: default
STATUS: pending-install
REVISION: 1
DESCRIPTION: Dry run complete
TEST SUITE: None
HOOKS:
MANIFEST:
---
# Source: test/templates/cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
data:
  test.conf: |
    test including .conf file

• Without .helmignore, both files are globbed into the configmap, and the pod template is rendered.
• With .helmignore containing *.txt and pod.yaml only the non .txt file is globbed into the configmap, and the pod is not rendered.

Interesting, digging up my reference where I think we deemed .helmignore was not being used.

ah, I was mistaken: helm/helm#12592 (comment)

User was reporting .helmignore was not being respected during helm package. But this just seems like an outright bug.

We need to specify that we (presumably) will only support a single .helmignore file (in the root of the chart). Or, we will match git's recusive .gitignore behavior:

Patterns read from a .gitignore file in the same directory as the path, or in any parent directory (up to the top-level of the working tree), with patterns in the higher level files being overridden by those in lower level files down to the directory containing the file. These patterns match relative to the location of the .gitignore file.

(and iirc, there is text which specifys/assumes .helmignore is in the root of the chart filesystem layout)

Good call-out. Added a "File Location" subsection clarifying that .helmignore loads only from the chart root (existing intended behavior).

For subchart .helmignore files specifically, added this as an Open Issue - unclear if the current behavior (ignoring them) is intended, a bug, or an oversight. I'll investigate and raise at the next dev meeting. For now, this HIP preserves existing behavior.

We should also perhaps include the equivalent of:

Git does not follow symbolic links when accessing a .gitignore file in the working tree.

Git has a specific reasons to not follow:

Git does not follow symbolic links when accessing a .gitignore file in the working tree. This keeps behavior consistent when the file is accessed from the index or a tree versus from the filesystem.

This rationale does not exactly apply to Helm I think. If we want to be consistent with .gitignore, we would want to apply this to Helm.

Otherwise, this perhaps the same question as to what helm package should do with respect to external symlinks.

Git's symlink note is specific to Git's consistency between index/tree and filesystem access - Helm has no equivalent concept. This HIP addresses file targeting syntax only; Helm's existing symlink handling (following symlinks before applying ignore rules) is unchanged and out of scope.

PS - separate from this HIP - I do think we should better document Helm's symlink behavior. From looking at the code, and testing out to make sure - here's what I see as helm package symlink behavior (current, unchanged by this HIP):

1. Symlinked .helmignore: Helm follows the symlink to read the ignore rules - works as if the file were in-place
2. Symlinks in chart content: Helm follows symlinks and expands them into the packaged tarball (the symlink becomes a regular file containing the target's content, not a symlink reference)
3. Interaction with .helmignore:
   • Ignoring a symlink: excludes the symlink itself from the package
   • Ignoring a symlink's target: the symlink still resolves and becomes a file in the package (symlink resolution happens before ignore rules apply)
4. Security restriction: External symlinks to certain sensitive paths are blocked per https://helm.sh/blog/2019/10/30/helm-symlink-security-notice/

nitpick: This list might not be exhaustive

Good catch - added: "This list is representative; the matching logic applies wherever chart files are loaded or accessed."