Up until now, the reana.yaml file has been validated by defining its JSON schema (source). This validation is rather strict, as for example a reana.yaml file that contains additional properties not defined in the schema is considered invalid.
This helps us catch errors such as misspelled property names, but at the same time it limits a lot which changes we can make to the schema while being backward compatible with older reana-client versions. As an example, we have recently introduced the tests property, but we cannot update the workflow demos we have on GitHub as they will not run when using an older version of reana-client.
We should investigate whether we should make validation less strict, by reporting unexpected properties as warnings instead of errors. We should also investigate whether we should expose these warnings in the UI, for example when launching workflow with Launch-on-REANA.
Up until now, the
reana.yamlfile has been validated by defining its JSON schema (source). This validation is rather strict, as for example areana.yamlfile that contains additional properties not defined in the schema is considered invalid.This helps us catch errors such as misspelled property names, but at the same time it limits a lot which changes we can make to the schema while being backward compatible with older reana-client versions. As an example, we have recently introduced the
testsproperty, but we cannot update the workflow demos we have on GitHub as they will not run when using an older version of reana-client.We should investigate whether we should make validation less strict, by reporting unexpected properties as warnings instead of errors. We should also investigate whether we should expose these warnings in the UI, for example when launching workflow with Launch-on-REANA.