Support top-level enums in CRDs

[sbernauer]

Currently only top-level structs are supported. Enums are supported as well (with some limitations) but not at top-level.

Motivation

I want to specify a CRD with a top-level enum

Solution

Added support for top-level enums

[codecov-commenter]

Codecov Report

Merging #856 (8805251) into master (116a970) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #856   +/-   ##
=======================================
  Coverage   70.56%   70.57%           
=======================================
  Files          59       61    +2     
  Lines        4212     4244   +32     
=======================================
+ Hits         2972     2995   +23     
- Misses       1240     1249    +9     

Impacted Files	Coverage Δ
kube-derive/src/custom_resource.rs	12.80% <ø> (ø)
kube-derive/tests/crd_enum_test.rs	100.00% <100.00%> (ø)
kube-client/src/client/mod.rs	68.15% <0.00%> (-2.11%)	⬇️
kube-runtime/src/wait.rs	68.00% <0.00%> (-2.00%)	⬇️
kube-derive/tests/crd_schema_test.rs	100.00% <0.00%> (ø)
kube-client/src/client/builder.rs	71.92% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 116a970...8805251. Read the comment docs.

[nightkr]

I'm not sure I'd encourage anyone to actually use this, but I also can't really justify forbidding it entirely.

[sbernauer]

I'm a little bit surprised, what are the disadvantages that you see when using a top-level enum?

[nightkr]

I'd guesstimate that most CRDs will have at least some fields that are common between variants, and using enums will make it harder to transition to those later. You could do something like:

struct FooKind {
    shared: String,
    #[serde(flatten)]
    method: FooKindMethod,
}

enum FooKindMethod {
    Foo { ... },
    Bar { ... },
}

But that feels like it would get clunky and unclear to document which fields are mutually exclusive with which.

[clux]

as an addendum to what Teo is saying:

It's a funny thing about the versioning of kubernetes crds that most people are almost never bumping the apiVersion and instead keep making tiny-non-breaking changes to it (adding new options, merely marking fields as deprecated) until some major release. Enums make that slightly harder. But I don't see any other reasons why you would want to be careful with such a spec.

[sbernauer]

Thanks for your feedback!
I'm with you that the usage of a top-level Enum must thought through but can also think of some cases where it is useful.

[clux]

Agreed. Edge-case, but has potential.

CI wise, I think github was struggling earlier, so it looks like you might need to push again or do the DCO thing (the action has details).

[sbernauer]

There is something strange going in the clippy check. cargo +nightly clippy works for me locally.
I'm trying to look into it.

[sbernauer]

Checks are blocked by briansmith/ring#1469

[clux]

Oh, ok, whatever. We can fix-forward on clippy. I'l just merge this now that DCO and all important checks are green.

[sbernauer]

Thanks a lot!