I've tracked the issue down to the lack of kubeconfig in CI. This is definitely a bug in helm, as it should not require a kubeconfig or any contact with any kubernetes cluster in order to generate a template.

The following patch makes it work for our purposes:

diff --git a/pkg/cli/environment.go b/pkg/cli/environment.go
index dac2a4bc..d8a25c18 100644
--- a/pkg/cli/environment.go
+++ b/pkg/cli/environment.go
@@ -223,6 +223,9 @@ func (s *EnvSettings) Namespace() string {
        if ns, _, err := s.config.ToRawKubeConfigLoader().Namespace(); err == nil {
                return ns
        }
+       if s.namespace != "" {
+               return s.namespace
+       }
        return "default"
 }

If I summarize my understanding of the above: helm template ignores the --namespace flag?

Yes, it ignores the --namespace flag, but only if you don't have a working kube config.

I think you're right, and this is a bug. A PR would be appreciated please.

@gjenkins8 There already is one #12126

I couldn't duplicate this behavior. I unset KUBECONFIG set HOME=/tmp and ran helm template --namespace foo . with the attached chart and it displayed the namespace correctly.

namespacetest.zip
(for some reason github wouldn't agree that my tgz file was a tgz)

@joejulian When I was testing this change, I just moved my ~/.kube directory. Perhaps something is not respecting the KUBECONFIG or HOME vars.

@alex-hunt-materialize

Nope, still no failure.

$ unset KUBECONFIG                                                                                                                                                                                                                                                                                                           

$ mv ~/.kube ~/.kubex                                                                                                                                                                                                                                                                                                        

$ helm template --namespace foo .                                                                                                                                                                                                                                                                                            #
---
# Source: namespacetest/templates/test.yaml
namespace: foo

$ set | grep KUBECONFIG   

I'll need a way to reproduce this problem with that chart in order to be able to approve this PR.

I've also been unable to reproduce it now, but I think my coworker just hit this today. I've asked them to see if they can isolate the reproduction.

Looking at the code, "default" will be used instead of the specified value if an err is encountered in s.config.ToRawKubeConfigLoader().Namespace() in the code snippet you have pointed out.
I would suggest adding a log statement to that code to help identify the error you are hitting.
I can get the same behaviour by setting --kubeconfig to a non-existing file, which I guess is not what you are doing but confirms that the default namespace will be taken when an error is encountered here, its just a matter of identifying the error you are getting in your scenario which an extra log statement should help with

diff --git a/pkg/cli/environment.go b/pkg/cli/environment.go
index dac2a4bc..105c7202 100644
--- a/pkg/cli/environment.go
+++ b/pkg/cli/environment.go
@@ -25,6 +25,7 @@ package cli
 
 import (
        "fmt"
+       "log"
        "net/http"
        "os"
        "strconv"
@@ -220,9 +221,11 @@ func (s *EnvSettings) EnvVars() map[string]string {
 
 // Namespace gets the namespace from the configuration
 func (s *EnvSettings) Namespace() string {
-       if ns, _, err := s.config.ToRawKubeConfigLoader().Namespace(); err == nil {
+       ns, _, err := s.config.ToRawKubeConfigLoader().Namespace()
+       if err == nil {
                return ns
        }
+       log.Printf("Error while fetching namespace %s", err)
        return "default"
 }

@MichaelMorrisEst Thank you for coming up with a reproduction! I am also able to reproduce it with that, or if I put invalid yaml into ~/.kube/config.

I'm surprised helm template needs to interact with kubernetes or its configs at all, though. The output of helm template has nothing cluster-specific in it, and a primary use case of helm template is to generate configs that could be applied to multiple clusters or parsed with alternative tools doing their own modifications. In this case, we're explicitly providing the namespace, so why would it ever look in the config?

I even think that my original fix is sub-optimal, as it should probably be above the line that reads the config.

diff --git a/pkg/cli/environment.go b/pkg/cli/environment.go
index dac2a4bc..fbd82b80 100644
--- a/pkg/cli/environment.go
+++ b/pkg/cli/environment.go
@@ -220,6 +220,9 @@ func (s *EnvSettings) EnvVars() map[string]string {
 
 // Namespace gets the namespace from the configuration
 func (s *EnvSettings) Namespace() string {
+       if s.namespace != "" {
+               return s.namespace
+       }
        if ns, _, err := s.config.ToRawKubeConfigLoader().Namespace(); err == nil {
                return ns
        }

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

Any update on this? Helm really shouldn't need to interact with kubernetes to template yaml files.

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

Definitely still a bug

Still a bug, and my PR is still a merge-able fix waiting for review #12126