Long strings are marshalled to invalid YAML; incorrect line breaks inserted

[tomasaschan]

When serializing an object that contains a very long string in its value, the resulting YAML has line breaks seemingly at random. This seems to be a bug in gopkg.in/yaml.v2 that is fixed in gopkg.in/yaml.v3, but discussions in #18 and #61 seem to imply that migrating is nontrivial.

To reproduce, put the following in a file repro_test.go:

import (
	"fmt"
	"testing"

	yamlv2 "gopkg.in/yaml.v2"
	yamlv3 "gopkg.in/yaml.v3"
	yamlk8s "sigs.k8s.io/yaml"

	"gotest.tools/assert"
)

func TestYamlV2(t *testing.T) {
	runTest(t, yamlv2.Marshal)
}

func TestYamlV3(t *testing.T) {
	runTest(t, yamlv3.Marshal)
}

func TestYamlK8s(t *testing.T) {
	runTest(t, yamlk8s.Marshal)
}

func runTest(t *testing.T, marshaller func(interface{}) ([]byte, error)) {
	long_string := "a very long string that might have to be broken into multiple lines in order to fit nicely in the output pane"
	j := map[string]string{
		"foo": long_string,
	}
	y, err := marshaller(j)
	if err != nil {
		t.Fatalf("failed converting: %v", err)
	}

	assert.Equal(t, fmt.Sprintf("foo: %s\n", long_string), string(y))
}

then run go mod init; go mod tidy; go test ./... to see the v2 and k8s tests fail, but not v3:

--- FAIL: TestYamlV2 (0.00s)
    repro_test.go:36: assertion failed: 
        --- ←
        +++ →
        @@ -1,2 +1,3 @@
        -foo:·a·very·long·string·that·might·have·to·be·broken·into·multiple·lines·in·order·to·fit·nicely·in·the·output·pane
        +foo:·a·very·long·string·that·might·have·to·be·broken·into·multiple·lines·in·order
        +··to·fit·nicely·in·the·output·pane
         
        
--- FAIL: TestYamlK8s (0.00s)
    repro_test.go:36: assertion failed: 
        --- ←
        +++ →
        @@ -1,2 +1,3 @@
        -foo:·a·very·long·string·that·might·have·to·be·broken·into·multiple·lines·in·order·to·fit·nicely·in·the·output·pane
        +foo:·a·very·long·string·that·might·have·to·be·broken·into·multiple·lines·in·order
        +··to·fit·nicely·in·the·output·pane

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[tomasaschan]

/remove-lifecycle stale

[brianpursley]

There are plans to fork go-yaml which should allow this to be fixed in the newly forked repo.

Kustomize has a similar issue open.

[KnVerey]

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: go-yaml/yaml#670. This repo deliberately opted not to set it by default: #62 (comment). Consumers who want the behaviour change should call yaml.FutureLineWrap(). Changing the default would not be possible without a major version bump IMO.

[brianpursley]

Thanks for the background @KnVerey

So in @tomasaschan's original example above, it sounds like this would be a way to avoid wrapping:

func TestYamlK8s(t *testing.T) {
        yamlv2.FutureLineWrap()
	runTest(t, yamlk8s.Marshal)
}

It's sort of unfortunate how go-yaml implemented that option globally, as there doesn't appear to be a way to unset it or check its value even.

At least FutureLineWrap() is a workaround people can use for now.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[brianpursley]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[tomasaschan]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.