validate/validate_test: Add linux.rootfsPropagation checks #476
Conversation
wking
force-pushed
the
json-schema-rootfs-propagation-test
branch
from
e149fb6 to
c66321d
Compare
To demonstrate that this is covered by the 1.0.0 JSON Schema checks, and show that the omitempty protects us from errors for empty-string values despite there being no empty-string entry in [1]. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/schema/defs-linux.json#L4-L11 Signed-off-by: W. Trevor King <[email protected]>
wking
force-pushed
the
json-schema-rootfs-propagation-test
branch
from
c66321d to
2cbb341
Compare
| config: &rspec.Spec{ | ||
| Version: "1.0.0", | ||
| Linux: &rspec.Linux{ | ||
| RootfsPropagation: "", |
There was a problem hiding this comment.
"" is not valid value for RootfsPropagation why error is ""?
There was a problem hiding this comment.
"" is not valid value for RootfsPropagation why error is ""?
I expect because it's omitempty, although I haven't tracked that down to specific gojsonschema code.
There was a problem hiding this comment.
I think omitempty means it can be unset but not ""
There was a problem hiding this comment.
I think omitempty means it can be unset but not ""
For a non-pointer omitempty like RootfsPropagation, an empty string is as close as you can get to unset.
There was a problem hiding this comment.
I think the RootfsPropagation: "" test should be deleted.
There was a problem hiding this comment.
I think the
RootfsPropagation: ""test should be deleted.
Why? With the current non-pointer property, that's how you explicitly unset the property. I think we need to be sure clearing RootfsPropagation is legal, because as this thread demonstrates, it's not immediately obvious.
There was a problem hiding this comment.
If it is not set, its value is also "", which is repeated with the previous test (without setting the value), and I think the test of this value is meaningless.
There was a problem hiding this comment.
If it is not set, its value is also "", which is repeated with the previous test (without setting the value)...
Yeah, but it doesn't hurt to double check, and the explicit-empty-string case surprised @Mashimiao at first. If test rephrasings help expose surprises, I think we want them.
|
LGTM |
1 similar comment
|
LGTM |
To demonstrate that this is covered by the 1.0.0 JSON Schema checks, and show that the omitempty protects us from errors for empty-string values despite there being no empty-string entry in the JSON Schema.
These tests are in support for #473.