feat: add fromJson and mustFromJson to values func map

[wI2L]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Feature: This adds two new functions fromJson and mustFromJson to the func map of the Values object.

• What is the current behavior? (You can also link to an open issue here)

Currently, one can use the toJson function of the Sprig project to encode a value to JSON, but the inverse is not available.

• What is the new behavior (if this is a feature change)?

A JSON document can be decoded into a data structure, e.g {{eval `varReturningJSON` | fromJson}}, or {{fromJson `{"a":"b"}`}}.

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

New feature, no breaking changes.

• Other information:

Similar feature request is still on hold for Sprig: Masterminds/sprig#230

[ovh-cds]

CDS Report test#763.0 ✘

• Stage 1
  • Test ✘

[loopfz]

How about returning a (possibly zero value) reflect.Value instead of interface?
See field implementation, it gets properly considered as a zero value for eg coalesce, default, '' replacement by the text tempmate engine, etc

[wI2L]

Good idea. What should we consider as "zero-value" in the context of a JSON-value tho ?
reflect.ValueOf(nil) will return the zero Value, which is great, but what about empty string, zero numbers, and so on ?

[loopfz]

I think it'd be interesting to describe a common use case for this here

[wI2L]

Yes. I guess, the most common use case we could document is to return a JSON stringified data structure from a JavaScript expression (object, array), and use one of its members in the template.
Example: {{(eval `myExpression` | fromJson).myArr}} or {{(eval `myExpression` | fromJson).myObj}}.

[wI2L]

One issue I couldn't figure how to circumvent yet, is the fact that a value extracted from a data-structure decoded with the introduced functions will always be converted to the Golang textual representation of their type.

See the following test case TestJSONParsing:

  assert.Equal(t, "utask", output["a"])
  assert.Equal(t, "666", output["b"])
  assert.Equal(t, "map[k:v]", output["c"])
  assert.Equal(t, "[1 2 3]", output["d"])

We are bound by the YAML spec, since we MUST quote our blocks in the template:

  a: '{{(eval `rawJSON` | fromJson).a}}'
  b: '{{(eval `rawJSON` | mustFromJson).b}}'
  c: '{{(eval `rawJSON` | mustFromJson).c}}'
  d: '{{(eval `rawJSON` | fromJson).d}}'

The idea is to be able to pass a map or slice as the input of a subtask without having the value converted to a string.

  variables:
    - name: myVariable
      expression: >
        var o = ["1", "2", "3"];
        JSON.stringify(o);

  myStep:
    action:
      type: subtask
      configuration:
        template: my-template
        input:
          foobar: '{{eval `myVariable` | fromJson}}' # <-- will pass '[1 2 3]'

The field input is a map[string]interface{}, how do we pass a Go slice without the string conversion when the myVariable expression evaluation returns a JSON array ?

[wI2L]

I think we can't do more about about the issue I raised in my previous comment #164 (comment). The implementation is good enough for now, we can still leverage the new fromJSON functions for useful cases.

@rbeuque74 A second review would be nice, I'll address the minor changes suggested by @loopfz.