Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line with space character followed by \n breaks Files.Glob templating #5446

Closed
juv opened this issue Mar 14, 2019 · 8 comments
Closed

Line with space character followed by \n breaks Files.Glob templating #5446

juv opened this issue Mar 14, 2019 · 8 comments

Comments

@juv
Copy link

juv commented Mar 14, 2019

Output of helm version:

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

What happens:

  1. I am glob'ing files into a config map with {{ tpl ( (.Files.Glob "conf/*").AsConfig ) . | indent 4 }}.
  2. Templating of the files fail with the following error:
    <tpl ((.Files.Glob "c...>: error calling tpl: Error during tpl function execution for ___TEXTUAL OUTPUT OF ALL FILES IN THE FOLDER___ .... template: my-chart/templates/configmap/my-chart.yaml:229: unclosed action

Cause of the issue:
I have an xml file in the folder I'm glob'ing.
In the middle of the xml content, I had a line which contained a space character and a following new line character like this

    <authorizer>\n
        <identifier>file-provider</identifier>\n
{SPACE_CHARACTER_HERE}\n
        <property name="whatever"></property>\n
    </authorizer>\n

This line with space character + \n breaks the templating function entirely, giving the error mentioned above. When I simply remove the space character and just leave the \n, everything works like expected.

@juv
Copy link
Author

juv commented Mar 14, 2019

Same error happens in the latest version Client: &version.Version{SemVer:"v2.13.0", GitCommit:"79d07943b03aea2b76c12644b4b54733bc5958d6", GitTreeState:"clean"}

@hickeyma
Copy link
Contributor

@juv May I ask what is the reason for \n on every line? Is this because you editor messed up the encoding?

@hickeyma
Copy link
Contributor

hickeyma commented Mar 14, 2019

I was not able to reproduce it using this simple example.

$ cat testchart1/test.txt 
<authorizer>
   <identifier>file-provider</identifier>
 
   <property name="whatever"></property>
</authorizer>

$ cat testchart1/templates/configmap.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
{{ tpl ( (.Files.Glob "test.txt").AsConfig ) . | indent 4 }}

$ helm template testchart1/
---
# Source: testchart1/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
    test.txt: "<authorizer>\n   <identifier>file-provider</identifier>\n \n   <property
      name=\"whatever\"></property>\n</authorizer>\n"
   

If you can provide me with more information, I will try and reproduce.

@hickeyma
Copy link
Contributor

It also works with the \n in it.

$ cat testchart1/test2.txt
<authorizer>\n
   <identifier>file-provider</identifier>\n
 \n
   <property name="whatever"></property>\n
</authorizer>\n

$ cat testchart1/templates/configmap.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
{{ tpl ( (.Files.Glob "test2.txt").AsConfig ) . | indent 4 }}

$ helm template testchart1/
---
# Source: testchart1/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
    test2.txt: |
      <authorizer>\n
         <identifier>file-provider</identifier>\n
       \n
         <property name="whatever"></property>\n
      </authorizer>\n

@juv
Copy link
Author

juv commented Mar 19, 2019

@hickeyma I can confirm that this works as intended on my personal computer. I tried to reproduce it with \r\n and \n but the templating seems fine. Note that I am using Windows 10 on both machines. I will try out tomorrow on my computer at work and let you know.

@juv
Copy link
Author

juv commented Mar 20, 2019

I can't seem to be able to reproduce this anymore. A weird part is that another colleague of mine had the same issue. I will close this for now, until I am able to reproduce it.

@juv juv closed this as completed Mar 20, 2019
@doernemt
Copy link

Issue is closed, but anyway: I had the same problem (on Windows 7, K8S on AKS) and was able to resolve it by converting the line endings from CRLF to LF (Unix-style).

@stephen-harris
Copy link

I've just encountered this too. For me converting line endings did not fix it. However removing any instance of a space before a newline fixed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants