Add nullable to optional fields with x-kubernetes-int-or-string

[doxxx93]

Motivation

Fixes #1869

When using Option<IntOrString> or Option<Quantity> (k8s-openapi 0.26.x) in CRD specs, the generated schema is missing nullable: true, causing server-side apply to fail with:

Invalid value: "null": spec.foo in body must be of type integer,string: "null"

The root cause is that schemars' AddNullable transform only adds nullable: true to schemas with a type property. However, IntOrString and Quantity schemas only have x-kubernetes-int-or-string: true without a type, so they're skipped.

Solution

Add OptionalIntOrString transform that:

1. Iterates over object properties
2. For properties NOT in the required list that have x-kubernetes-int-or-string: true
3. Adds nullable: true if not already present

This mirrors how Go's controller-tools handles nullable for pointer types (*IntOrString).

Before:

{ "x-kubernetes-int-or-string": true }

After:

{ "x-kubernetes-int-or-string": true, "nullable": true }

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.1%. Comparing base (5ad6c18) to head (4e8298a).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1885     +/-   ##
=======================================
+ Coverage   76.0%   76.1%   +0.1%     
=======================================
  Files         85      85             
  Lines       8285    8313     +28     
=======================================
+ Hits        6296    6321     +25     
- Misses      1989    1992      +3     

Files with missing lines	Coverage Δ
kube-core/src/schema.rs	96.3% <100.0%> (+0.5%)	⬆️
kube-derive/src/custom_resource.rs	84.3% <ø> (ø)
kube-derive/tests/crd_schema_test.rs	100.0% <100.0%> (ø)

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[clux]

Looks great to me, thank you!

[doxxx93]

@clux Just curious - when do you think the next release might be? Would it coincide with the next k8s-openapi release (the "Add v1.35.0 and drop v1.30" commit from https://github.com/Arnavion/k8s-openapi)?

[clux]

Yeah, was planning on releasing with that. (Usually there are a lot of confused people who tries to use the new k8s-openapi with the current kube who gets mismatches if it's too out of sync).

If it's not by this week/next week I'll probably cherry pick some stuff into a 2-x branch and do another release.

[clux]

Will merge in this at least. Thank you!

[clux]

as a side-note. I guess if I'm considering cherry picking, we could probably merge all the outstanding breaking ones now.

[doxxx93]

yeah I think so too

[Arnavion]

Upstream 1.35 OpenAPI spec hasn't had any bugfixes after 1.35.0 that would cause further backward-incompatible changes in k8s-openapi, so I'll probably cut a new k8s-openapi release this weekend.