Skip to content

Conversation

sbernauer
Copy link
Member

WIP!

@sbernauer sbernauer self-assigned this Oct 8, 2025
@sbernauer sbernauer moved this to Development: In Progress in Stackable Engineering Oct 8, 2025
@sbernauer sbernauer closed this Oct 9, 2025
@sbernauer sbernauer reopened this Oct 9, 2025

assert_json_eq!(
schemars_schema,
json_schema!(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to go back to assigning so the assert isn't so nested and easier to read from start to end.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And keeping the commentary, eg:

// Initial check that the text schema above is correct for NormalEnum

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me. Naming things is hard, this way we avoid that 😂
Feel free to revert to the previous way

Copy link
Member

@NickLarsenNZ NickLarsenNZ Oct 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming things is hard

I agree, though by naming it appropriately, we convey share more information to the reader (which IMO parts of this module currently lacks, which is why it has been difficult to fix).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some adjustments here: 285ab64

I did move it back to owning and returning an owned Schema - but we can discuss that. I don't mind changing it back if you really want.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went back to the simpler checks at the start of the function, since the big pattern match is a little too much cognitive load (although very pretty), and uses unstable features.

Note: As described on the function, it is overly documented to express intent where it can be a little unclear. Ideally where would be some clearer official Kubernetes documentation on the differences between regular OpenAPI 3 schemas, and what Kubernetes accepts.
… there are no oneOfs at the top level of the schema
Note: At this point, there is some strange interaction with the new hoisting functions and the existing code whereby "properties" disappear.
Comment on lines +252 to +253
// #[cfg(test)]
// mod test {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll bring these back in once we make more progress (more as regression safe guards)

Comment on lines +472 to +475
// if anyOf with 2 entries, and one is nullable with enum that is [null],
// then hoist nullable, description, type, enum from the other entry.
// set anyOf to None
fn hoist_any_of_option_enum(incoming: SchemaObject) -> SchemaObject {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Properly document this one

Comment on lines +694 to +704
} else if let Schema::Object(SchemaObject {
object: None,
instance_type: variant_type,
metadata,
..
}) = variant
{
if *variant_type == Some(SingleOrVec::Single(Box::new(InstanceType::Object))) {
*variant_type = None;
*metadata = None;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably want to replace these existing hoisting functions. At least they are not working with the new code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Development: In Progress

Development

Successfully merging this pull request may close these issues.

2 participants