Document every public derived fn from kube-derive #919
Conversation
Fixes deny(missing_docs) issues interacting with kube-derive reported in Signed-off-by: clux <sszynrae@gmail.com>
Signed-off-by: clux <sszynrae@gmail.com>
kube-derive/src/custom_resource.rs
Outdated
| #visibility metadata: #k8s_openapi::apimachinery::pkg::apis::meta::v1::ObjectMeta, | ||
| /// Spec on derived type |
There was a problem hiding this comment.
ah, this is actually annoying... it means schemars will use this rather than what's in front of FooSpec:
expected:
"Spec on derived type"
actual:
"Our spec for Foo\n\nA struct with our chosen Kind will be created for us, using the following kube attrs"
via crd_derive tests. Probably need to try to re-use the docs for the type in here.
There was a problem hiding this comment.
have changed the dummy doc strings for a #[allow(missing_docs)] on the generated root struct instead...
this allows the schemas to pick up the right property, although it is slightly on the hackier side
Signed-off-by: clux <sszynrae@gmail.com>
clux
changed the title
This comment was marked as off-topic.
This comment was marked as off-topic.
|
hm, yeah, maybe. it's not something people have ever asked for, but if there's a legit case for it, we can probably consider adding an opt-out. |
|
Well one downside of the current approach is that we export CRD YAMLs with the auto-generated "blah blah auto-generated wrapper type for blahblahspec", which is only intended for the Rust-side devs. We can work around that, but it feels like it might be time to reconsider the more special cases we end up adding. |
Fixes deny(missing_docs) issues interacting with kube-derive reported in #918 cc @olix0r