attributes also can be declared as string (using variables)

[ndeloof]

This removes constraints on compose.yaml attributes as those can be set by variables, so we can't require value to be a number or format to be a duration, as ${VARIABLE} also is a valid value

[glours]

Do we have this validation somewhere else in the source code?

[ndeloof]

yes, NormalizeProjectName

[glours]

LGTM

[jhrotko]

should we create a type variable and add to all of these? a simple string is to relaxed of a restriction for this case

[ndeloof]

this schema is used

1. by IDEs to drive autocompletion and validation, and as such must allow use of strings so ${VARIABLE} is considered valid (and all variation of compose variable syntax)
2. in compose-go to check tree structure, but not node values. Failure to convert to go types is detected during unmarshalling

[jhrotko]

what I am saying is that with the current implementation 'banana' is a valid value for all these changes. Not necessarily the var syntax that we intend

[ndeloof]

sure, but such validation (which would require a complex regexp to express the variable syntax) would bring no benefit, as IDE won't use this for advanced validation AFAICT, and compose-go parser would anyway report an error
this schema is not required to provide a bullet-proof validation of a compose file, it's just a helper to define the yaml tree

[jhrotko]

my suggestion would be to create a definition for the ${VARIABLE} which should be like

    "variable_type": {
      "type": "string",
      "pattern":"^\$\{[a-zA-Z_$][a-zA-Z_$0-9]*\}$"
    },

assuming we want
${VAR}
${hehe_123}
${_123}
${123} -> no
${123yo} -> no
${_MY234}
${$MY}
${-MY} -> no

and then use it like

...
"attach": {
   "oneOf": [
        {"type": "boolean"},
        {"$ref": "#/definitions/variable_type"}
      ]
}

[glours]

we can't do something generic like this, because it could reference either boolean, integer values or more complex structs like ports or range of IPs which could be defined in multiple ways... and I'm not sure we want to redeclare all kind of type as we know compose-go will do the check when parsing the compose model

[jhrotko]

maybe I am understanding this wrong but my understanding is when you write ${VAR}, the schema will not interpret this value. This will be done by compose-go when loading the file (right?) So, in my point of view, if you want the schema to validate the current value ${VAR} is valid - which is a simple string with a pattern defined in compose-go

[ndeloof]

variable syntax is way more complicated. Can be ${VAR:-${SUBVAR?err}}
Also delay: 12${VARIABLE}s is a valid value

[ndeloof]

if you want the schema to validate the current value ${VAR} is valid

right, I don't want this to happen. I expect schema to validate the yaml tree structure, so I can safely assume I can access services.xx.mac_address. But interpolating value and validating a valid mac address should be implemented in compose-go, not by schema

[jhrotko]

I see, it can be more complex than just a simple $VAR