-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adopt a more flexible way of resolving $ref references #82
Comments
IIRC this was not necessarily because of the "$ref" itself, but it was rather in the way that the openapi2proto code expects only objects. I think something can be worked out, but I think it's more of a matter of coming up with a minimal test case first. |
I'm looking into this in the context of #128. https://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03 states in section 3:
That seems pretty clear - "$ref": {
"type": "string"
} be valid according to the OpenAPI spec? |
Fixes nytimes#128 and nytimes#82. Changes: - Ignore $ref declarations that are not strings (dubious) - Allow builtins as RPC return types - Update Kubernetes proto fixture (dubious)
Fixes nytimes#128 and nytimes#82. Changes: - Ignore $ref declarations that are not strings (dubious) - Allow builtins as RPC return types - Update Kubernetes proto fixture (dubious)
We still have the kubernetes.json fixture commented out from tests due to a (valid) JSON Schema $ref to point to a string type:
We should be able to detect this and simply resolve it as a
type: string
.Hopefully this is the only thing preventing us from using the k8s spec as a fixture :)
The text was updated successfully, but these errors were encountered: