When combining helm templates with kustomize overlays, a line break is inserted when the line is very long and contains spaces.
Tested versions: 2.0.1 and 2.0.3
Using test/base.yml:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: test
labels:
app.version: "{{ .Values.services.mariadb.app.version }}"
spec:
template:
spec:
containers:
- name: mariadb
image: "thisIsAReallyLongRepositoryLinkThatResultsInALineBreakWhenBuildingWithKustomize/mariadb:{{ .Values.services.mariadb.image.version }}"
and test/kustomization.yml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- base.yml
results in
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app.version: '{{ .Values.services.mariadb.app.version }}'
name: test
spec:
template:
spec:
containers:
- image: thisIsAReallyLongRepositoryLinkThatResultsInALineBreakWhenBuildingWithKustomize/mariadb:{{
.Values.services.mariadb.image.version }}
name: mariadb
Expected Behavior:
app.version label is enclosed in single quotes. I would expect that either the quotes are not removed at all or the quoting behavior is constantI think if https://github.com/go-yaml/yaml/pull/455 gets merged that might be the signal to migrate to yaml.v3, and unlimited line lengths...
This behavior is still in v3.0.1. Using the same input files, the output has line breaks:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app.version: '{{ .Values.services.mariadb.app.version }}'
name: test
spec:
template:
spec:
containers:
- image: thisIsAReallyLongRepositoryLinkThatResultsInALineBreakWhenBuildingWithKustomize/mariadb:{{
.Values.services.mariadb.image.version }}
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Hi guys,
there is a workaround for this issue?
Have the same issue here. Need to keep the formatting as is without breaking long lines. Any ideas?
@kristofferahl, we worked around this by using:
attribute: |
very long line
Not sure if this is semantically 100% equal, though. It mitigated the issue in our specific case.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/reopen
@laverya: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
There's a fix in gopkg.in/yaml.v2, now released as v2.3.0 - I'll make a PR to update kustomize to this version. (basically, if the string doesn't have newline literals in it, v2.3.0 won't split the string over multiple lines when encoding things - previously it would wrap before 80 characters)
Just validated, and 3.6.1 still exhibits this behavior:
kustomization.yaml
resources:
- deployment.yaml
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
spec:
replicas: 1
selector:
matchLabels:
component: test
template:
metadata:
labels:
component: test
spec:
containers:
- name: test
image: "test"
env:
- name: DATABASE_URL
value: postgres://{{repl ConfigOption "database_user"}}:{{repl ConfigOption "database_password"}}@db.{{repl Namespace}}.svc.cluster.local:5432/db
yields this:
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
spec:
replicas: 1
selector:
matchLabels:
component: test
template:
metadata:
labels:
component: test
spec:
containers:
- env:
- name: DATABASE_URL
value: postgres://{{repl ConfigOption "database_user"}}:{{repl ConfigOption
"database_password"}}@db.{{repl Namespace}}.svc.cluster.local:5432/db
image: test
name: test
$ kustomize version
{Version:3.6.1 GitCommit:c97fa946d576eb6ed559f17f2ac43b3b5a8d5dbd BuildDate:2020-05-28T01:07:36+01:00 GoOs:darwin GoArch:amd64}
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
We should get a unit test in place that displays this behavior (or confirms that it's gone).
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Most helpful comment
@kristofferahl, we worked around this by using:
Not sure if this is semantically 100% equal, though. It mitigated the issue in our specific case.