Open semihbkgr opened 3 weeks ago
1- Would it be preferable to return a
TaskfileDecodeError
in theUnmarshalYAML
function when parsing the yaml intoInclude
? This approach could make the error message more descriptive.However, I aligned this error with the existing one we return when the
Taskfile
is not existing ("no such file or directory"), which is why the error is returned after the parsing step.
The distinction here is whether or not taskfile:
is required in the schema or whether it is valid to be empty in the schema, but causes an error when processing.
Opinion: I think we should error in the UnmarshalYAML
method and return a TaskfileDecodeError
and we should update the schema.json
to mark taskfile:
as a required field when using an include:
object. I'm not sure if jsonschema can specify non-empty on a scalar value? but if it can, we should do that too. @andreynering @vmaerten feel free to weigh-in.
2- Should we differentiate between null and empty string values, or should we treat them the same and return an error for both?
I can't see a situation where an empty string is useful.
@pd93 We can use "minLength": 1
in the json schema to ensure the taskfile value is not empty.
fixes #1881
This makes the
taskfile
field withininclude
required, disallowingnull
(unspecified) or empty values, even if inlined.I’d like to clarify two points, @pd93:
1- Would it be preferable to return a
TaskfileDecodeError
in theUnmarshalYAML
function when parsing the yaml intoInclude
? This approach could make the error message more descriptive.However, I aligned this error with the existing one we return when the
Taskfile
is not existing ("no such file or directory"), which is why the error is returned after the parsing step.2- Should we differentiate between null and empty string values, or should we treat them the same and return an error for both?