Skip to content
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

Support OpenAPI "title" field in CUE codegen #292

Open
joeblubaugh opened this issue May 27, 2024 · 0 comments
Open

Support OpenAPI "title" field in CUE codegen #292

joeblubaugh opened this issue May 27, 2024 · 0 comments

Comments

@joeblubaugh
Copy link
Contributor

When using CUE for resource descriptions, comments on the cue fields are turned into OpenAPI "description" fields. This is great. I'd also like to use the "title" field if possible. Immediate use case is doing some form-and-display building automation for certain resource types. By supplying both a title and a description, it's easier to understand that "myComplicatedEnumTypeName" can just be "Order Status" in a UI. However, I think this is useful in general.

A few ways we could perhaps do this:

  • First line is the title. Not great because comment strings start to get unwieldy and maybe repetitive. Example with no description text:
{
  // Order status
  orderStatus: "unknown" | "cancelled" | "shipped" | "delivered"
}

with description:

{
  // Order status
  // The state of this order. This can only be set by a seller or fulfilment partner.
  orderStatus: "unknown" | "cancelled" | "shipped" | "delivered"
}
  • We attempt to split and then sentence-case the name of the field, so "orderStatus" becomes "Order status" in the title.

This is a bit different from the way kubernetes does this, in that the base APIs don't supply a title, and they repeat the field name in the "description" field: "replicas is the number of currently active Pods in a Deployment" or similar.

(For solving my immediate use case I can also do something like ensure that the "description" string is parseable according to some simple standard I come up with, similar to this.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant