Render variable's default value with declared type when listing with JSON format

[rrjjvv]

Description

For variables that are typed (especially complex), one would expect the typing information to be used when formatting via JSON. This is already done correctly in the default table listing.

Given this bake file:

variable "foo_number" {
  type = number
  default = 11
}

variable "foo_string" {
  type = string
  default = "11"
}

variable "foo_set" {
  type = set(string)
  default = ["11"]
}

target "default" {}

one would expect to be able to extract the value from the set, but it doesn't work

$ docker buildx bake --list type=variables,format=json --progress quiet | jq 'map(select(.name=="foo_set").value[0])'
jq: error (at <stdin>:17): Cannot index string with number

since the values for all variables (whether complex or not) are output as strings:

$ docker buildx bake --list type=variables,format=json --progress quiet | jq 'map(.value)'
[
  "11",
  "[\"11\"]",
  "11"
]

It's trivial to work around, e.g.,

$ docker buildx bake --list type=variables,format=json --progress quiet | jq 'map(select(.name=="foo_set").value|fromjson)[0]'
[
  "11"
]

but it isn't ideal.

I overlooked this while implementing #3207. Fixing this could be considered a breaking change (for those parsing the output and already using a workaround), but it's possible there could be no impact given this has only been out for three weeks. I felt it better to get input prior to submitting a fix.

[tonistiigi]

I'm not so sure about this. I think one should expect consistent output and not different types. It is more likely that --list=variables would be used for discovery tools that are supposed to work on any project, rather that expecting a app-specific definition for a specific variable name.

[rrjjvv]

🤔 I can certainly understand that viewpoint. The most obvious solution to satisfy both the consumer and producer is to add a new typedValue key alongside the existing value key. But I don't actually need this functionality... I was simply parsing my own project and my (complex) values looked messy and wrong. And I'm guessing you'd be on the YAGNI side of the fence (wouldn't want it implemented if nobody is asking).

Let me know if you simply want me to close this.

[tonistiigi]

Yes, I think we can close this. cc @crazy-max