kustomize: Line breaks on long strings with spaces

@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.

I am still experiencing this with Kustomize version v4.5.2.

Please reopen this issue.

This is still an issue, with latest version of kustomize bundled with Argo CD 2.0.1. I use the kustomized-helm pattern, but kustomize corrupts the following

BEFORE

containers:
- name: createdb-{{ $index }}
  image: postgres:11-alpine # A relatively small official image that can run psql
  command:
    - sh
    - -c
    - >
        while ! pg_isready -U postgres -h {{ template "timescaledb.fullname" $ }}; do sleep 1; done;
        echo "${SQLCOMMAND}" | psql --file=- --echo-queries -d "${ACCESS_SVC_CONNSTR}" \
          --set ON_ERROR_STOP=1 \
          --set dbname="${DBNAME}"

AFTER

containers:
- name: createdb-{{ $index }}
  image: postgres:11-alpine # A relatively small official image that can run psql
  command:
    - sh
    - -c
    - >
        while ! pg_isready -U postgres -h {{ template "timescaledb.fullname" $ }}; do sleep 1; done;
        echo "${SQLCOMMAND}" | psql --file=- --echo-queries -d 
"${ACCESS_SVC_CONNSTR}" \

          --set ON_ERROR_STOP=1 \
          --set dbname="${DBNAME}"

adding yq in pipeline do fix this yaml

cat result.yaml | yq > new.yaml

v2 of go-yaml already exposes the option to change this behaviour. In fact, it was temporarily the default in v2.3 of that library, but the change was reverted at the request of the Kubernetes project in v2.4: https://github.com/go-yaml/yaml/pull/670. This repo deliberately opted not to set it by default: https://github.com/kubernetes-sigs/yaml/pull/62#discussion_r713015836. Consumers who want the behaviour change should call yaml.FutureLineWrap(). Changing the default in kubernetes-sigs/yaml would not be possible without a major version bump IMO.

Reading through the history here and on related issues, it sounds like Kustomize in particular has already thrashed on the wrapping behaviour. Indeed, we used the go-yaml version with the changed default between https://github.com/kubernetes-sigs/kustomize/pull/2679 and https://github.com/kubernetes-sigs/kustomize/pull/3667, which means v3.7.0 to v4.0.5 had no line limit set, and both before and after did. The revert was apparently specifically requested because of the kubectl integration, and we knew it would thrash the line length limit: https://github.com/kubernetes-sigs/kustomize/issues/3664.

Even if on the Kustomize side we could consider the wrapping to be purely a bug (such that we could accept the change in output as non-breaking and release without a major version bump), we would still have the problem of how to do it. Unfortunately yaml.FutureLineWrap() is a global toggle, so we cannot set it in code that kubectl will pull in, i.e. the relevant code–we already know that change is unacceptable in kubectl. So perhaps what we can do with our upcoming fork is not “fix” the wrapping (we can’t change it by default), but rather expose the flag on a per-encoding basis instead of globally, so that kustomize and kubectl kustomize could make the change without affecting the rest of kubectl.

This problem is extremely annoying. Is there any updates?

Unfortunately the following workaround not works in all cases:

key: |
  value

This construction adds a \n in the end of the line and not in all cases app is able to just ignore this \n. There’re |- and >- syntax, but unfortunately values created with them are still having line break in the middle of the line

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)

@laverya: You can’t reopen an issue/PR unless you authored it or you are a collaborator.

I 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…